[Python-Dev] tracker status options

[Steve Holden]

R. David Murray wrote:
> On Tue, 24 Mar 2009 at 21:27, "Martin v. L�wis" wrote:
> 
>>>     o consensus needed
>>>     o test needed
>>>     o patch needed
>>>     o patch needs work
>>>     o patch review
>>>     o commit review
>>>
>>> The first of these additional items is equivalent to your bullet item
>>> above.  I would propose that the issue, regardless of whether or not
>>> it is a bug fix or a feature request, goes into 'consensus needed'
>>
>> Well, there is always the "unset" state, which means "not triaged".
>> So if you propose that this should be the default initial state,
>> I'm opposed.
> 
> No, I was not suggesting it be the default state.
> 
>> Instead, would it help to add a "confirmed" state? For a bug, that
>> would mean that it was successfully reproduced; for a patch, it
>> was confirmed as desirable.
> 
> So, 'confirmed' instead of 'consensus needed' (or confirmed/approved,
> to cover feature requests), and 'patch is appropriate' that comes...I'm
> not quite sure where?
> 
>> If the person performing triage cannot confirm the bug, they should
>> reject the issue (or recommend rejection, in case they are unsure).
>> Somebody performing triage should never conclude with "I don't
>> know"; this would be time-wasting.
> 
> The cases I was considering are cases where in the comments on the ticket
> there is disagreement either on whether or not the bug is a bug or (more
> often) whether or not the feature is desirable, and at the patch stage
> whether or not the patch is the appropriate fix.  I think currently
> things sit in 'patch needed' until consensus is reached on the patch,
> but I haven't watched enough tickets progress yet to be sure :)
> Adding another stage here may be more confusing than it is helpful,
> seeing as I can't really figure out where it would go.
> 
> Did I guess correctly that the process for "recommending rejection"
> is to set the stage to 'commit/reject', the resolution to 'invalid'
> (or whatever is appropriate) and the status to 'pending'?  That
> seemed to work for the issue I did it to, in that someone came
> along and closed it shortly after that.
> 
>> If, for a bug, the reviewer disagrees that it would be a bug if the
>> behavior actually exists, then the issue should be closed (resolution
>> not-a-bug/invalid). If the reviewer agrees that it would be a bug,
>> but fails to reproduce it, a test is needed.
> 
> OK, so I guess I now understand how the current workflow is supposed to
> work: if its stage is 'unassigned', then it hasn't been accepted as a
> bug/enhancement yet, and triage should make that accept/reject judgement.
> 
> The tricky bit here for me is that I, as a new person doing triage,
> don't always feel comfortable in passing judgement on a bug or feature
> request.  So what would be the mechanism for a triage person to request a
> "passing of judgement" from someone with more experience/authority?  Post
> to python-dev?  Given such a mechanism, I think I would be comfortable
> with the current workflow, with the expectation that I would need to
> call for assistance less and less frequently over time, and ultimately
> only for those things where discussion among the devs really is needed.
> 
> Hmm.  Maybe I should write a short "guide to performing triage" and
> post it for feedback.
> 
Might I suggest studying the status values used by the Django team in
their Trac tracker instance. They seem to have a very methodical workflow.

http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
Holden Web LLC                 http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.org/