[Python-Dev] tracker status options

[R. David Murray]

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