On Tue Mar 24 02:06:29 CET 2009, Tennessee Leeuwenburg <tleeuwenburg at gmail.com> wrote: > Perhaps some developers have a well-established workflow and interpret these > flag in a particular, consistent fashion, however part of the purpose of the > issue tracker is to allow a diverse group to work on development as a group. > On that basis, I feel that more documentation, and clearer terminology, is > required in order to support the bug resolution process. > > I have identified some gaps in the workflow process which impact me > personally in classifying issues. These issues will not impact on all > developers; clearly they will be entirely superfluous, perhaps even > confusing, for some individuals. However the impact still remains for some. > There appears to be a general agreement that ability to distinguish between > issues on the following bases would be useful: > * Whether the nature of the requirement is still under debate or whether > it is well-understood So, having triaged a few issues, here are my thoughts. The current workflow is roughly: o test needed o patch needed o patch review o commit review One can look at these and see what needs to be done "next". I think that in practice the above list actually expands something like this: 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' whenever there is significant debate as to the validity of the bug or feature request. It moves to an appropriate later stage when agreement has been reached (which may be by fiat of a developer or the BDFL....so the triage people would need to know who can "pronounce"). The second addition is not as clearly useful. 'patch needs work' could be the result of a developer review, or of any other review. That is, at that stage we are trying to reach consensus that the patch is the correct solution to the problem or feature request. An issue could bounce back and forth between 'patch review' and 'patch needs work' multiple times (and it would probably be best if the patch submitter could request 'patch review'). But one could argue that the issue could just as easily be bounced back and forth between 'patch review' and 'patch needed', since one would need to read the comment stream to figure out what was actually going on anyway. I think it would be a useful addition, since it would enable someone to search for 'patch needed' in order to look for issues to pick up, whereas 'patch needs work' would indicate someone was working on it. (Of course, that someone could also stop working on it...but if one wished to find such issues, one could simply sort 'patch needs work' issues by last activity date.) Hmm. Or perhaps it should be "patch needs consensus", given the issue I'm looking at where I want to set it to this stage :) > * Whether the issue is "up for grabs" by any developer or whether > responsibility lies with an individual or group already Isn't that covered by 'assigned to'? > * Whether the issue is ready for more serious consideration by more > experienced or core developers Hmm. Theoretically that's covered by 'patch review'. Given that 'commit review' is (currently?) reserved for issues being considered for addition to a release candidate or final release, perhaps we need an additional stage 'core review' that would come after 'patch review'. Then triage could promote issues from 'patch review' to 'core review' if triage thinks it is ready for review by someone with commit privileges. This of course assumes that people other than core developers are actually doing patch review. I certainly intend to, but how many of us are there really going to be? -- 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