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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com