ubuntu-bugcontrol team mailing list archive

[C de-Avillez <hggdh2@xxxxxxxxxx>]

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..

Attachment: signature.asc
Description: OpenPGP digital signature