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. -- R. David Murray http://www.bitdance.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4