On 03/11/2011 04:27 AM, Roth Robert wrote: <snip/> >> "One that can easily be worked around by doing something different" > > I still wouldn't understand that, as it doesn't explain, how about > something like this > > "One that can easily be (worked around)/(fixed locally) by the > reporter until a developer fixes the problem in the package"
On 'fixed locally': I do not agree. 'fix' carries a stronger meaning: it has been set right, and will not fail again (because of that particular issue). A bypass is *not* a fix. A work around is *not* a fix. > Regarding the rewording of the bug list selection: > >> I think this as a result of the fact that triaging can mean the whole >> bug life cycle or the process of getting a bug to the Triaged bug >> status. I'm of the opinion that bugs you've touched that already in >> Triaged, Fix Committed/Released statuses are the ones we really want to >> see as those are the ones that have progressed the furthest in the bug >> life cycle - not just bugs that should be set to Triaged. So maybe the >> wording should be: > >> "Have a list of bug reports that you have worked on and that demonstrate >> that you understand the bug triaging process." > > I like this wording more than "Have a list of triaged bugs that > demonstrate you understand triaging.", because it does not say triaged > bugs explicitly, ********************************************************** > but still I don't know how to explain concisely that > it's not necessarily about bugs the applicant has fixed, ********************************************************** er, what? > but I think > that this can easily be understood a bit later, from the Direct > application section, 5th bullet: "Please list five or more bugs which > you have triaged and include an explanation of your Triage. Please > note that these bugs should be representative of your very best work > and they should demonstrate your understanding of the triage process > and how to properly handle bugs. For all the bugs in the list, please > indicate what importance (and explain the reasoning) you would give it > after becoming a member of the Ubuntu Bug Control team. Please use > urls in your list of bugs." > This clarified for me that the application doesn't have to show off > bugs fixed by himself/herself, only list bugs to "demonstrate your > understanding of the triage process and how to properly handle bugs". I think the major issue is one of misinterpretation, or mis-expectation: Bug Control is not about _fixing_ bugs, it is about triaging bugs (and triage control). Of course, almost always we are doing BOTH activities -- triaging and fixing --, but these are *different* processes, with different requirements. ..C..
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
