[Python-Dev] tracker status options

[Tennessee Leeuwenburg]

On Tue, Mar 24, 2009 at 11:00 AM, "Martin v. Löwis" <martin at v.loewis.de>wrote:

> >     That would be great. It occurs to me that if we wanted to use
> >     "Stage" settings, it would be easy to search for issues which are
> >     not closed by literally searching for 'not closed' rather than
> >     'open'. I think it's also unclear whether the 'pending' stage means
> >     'suspended pending additional user feedback' or 'resolution of this
> >     issue is impending'. My understanding was that it meant 'pending
> >     additional feedback' in the sense of awaiting, rather than imminent.
> >
> >
> > It's the latter; it's "pending feedback".
>
> Which "latter" (there seem to be multiple pairs in Tennessee's message)?
>
> In any case, it's not really "pending feedback". Instead, it means "if
> there is no feedback really soon, it will get closed". So closure is
> impending and imminent.


I think this indicates that the flag in not sufficiently self-descriptive.
My understanding, and I think the understanding of some others, is that this
flag indicates a suspension of development pending additional feedback,
rather the impending conclusion of development pending further feedback. In
some of my earlier emails to this list, other developers were happy to mark
issues that were being deferred as a result of requiring further
specification or clarification as "pending feedback", which is quite the
opposite of imminent closure.

While some may feel that the use of this flag is unambiguously used to
signify imminent closure, I respectfully point out the recent occasions
where confusion has occurred, and not just from a single individual.

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
   * Whether the issue is "up for grabs" by any developer or whether
responsibility lies with an individual or group already
   * Whether the issue is ready for more serious consideration by more
experienced or core developers

Since these issues relate primarily to the long-standing, dubious or complex
issues which are not fully resolved, often of lower priority, it is apparent
that more experienced developers will not find a lot of use in the addition
of further flag, but I don't see that their workflow would be frustrated
either.

I'm happy to put my time an effort into classification of low-priority
issues, classification, and code development for areas which would probably
not otherwise receive much attention. However, to do this effectively, I
need to be able to set up additional parameters against the issues to
support the search requirements needed. Doing this on the development
tracker seems to be the best approach, seeing as there seems to be some
closely-held positions regarding the existing set of flags -- it would be
quite inappropriate to disrupt existing workflows for the more experienced
and core developers without demonstrating the value of new flags. However, I
do feel that adding flags is of very clear value to the development process
overall.

My suggestion remains to add two additional attributes, either as "stage" or
"status" options (personally I still feel 'status' is appropriate, but I
don't mind where they go):
   * Under discussion
   * Under development

This would flag "Open" issues as being up for grabs by any developer, "Under
discussion" as something which is not ready for a developer to start work on
a solution and which is still being worked out. "Under development"
similarly means that everyone who needs to be involved is already involved.
Issues that were "under discussion" or "under development" would drop back
to "Open" after a month of inactivity. Issues which could not be advanced
without further feedback would be marked as "suspended pending feedback",
and never drop back to Open. The current "pending feedback" which appears to
be used to indicate imminent closure should perhaps be altered to "pending
closure".

Thus, "Open" indicated triage is required. The default view on the issue
tracker should be "all issues not closed". The default view for a triage
nurse would be "show me everything that is open".

I'm all for more debate on options for these new flags, but I haven't heard
a whole lot of alternatives to date...

Cheers,
-Tennessee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090324/5921bf7a/attachment-0001.htm>