[Python-Dev] Addition of further status options to tracker
Terry Reedy
tjreedy at udel.edu
Tue Mar 10 05:07:37 CET 2009
Brett Cannon wrote:
>
>
> On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg
> <tleeuwenburg at gmail.com <mailto:tleeuwenburg at gmail.com>> wrote:
>
> Hi all,
>
> I am beginning reviewing some more issues in the tracker. I think it
> would be useful to have the following status options (new status
> options marked with a '+'):
> Open: Means that the issue has been created and not further reviewed
> + Request Approved: Means that the issue is marked as worth
> further development by the community
> + Specification Approved: Means that the functionality to be
> developed is written down in some form, and agreed at least in
> general terms (preferably in fairly specific terms)
> + Under Development: Means that an implementation is currently
> under development
> Pending Feedback: Means that work is suspended pending feedback
> + Under Final Review: Means that a patch has been submitted and
> may be a flag that core developers can usefully review the work done
> without having to revisit the whole process
> Closed: Means that the issue is either suspended indefinitely or
> has been resolved (see resolution value)
>
>
> I assume you want all of this for the Status field, correct?
>
> As for the options, some of these overlap with the Stage field. For
> instance, if something has been set to any stage other than
> "accepted/rejected" it means it needs to be looked into, so that
> duplicates your "Request Approved" status. Similar thing with the review
> stages and "Under Final Review".
>
> But a general "under development" status would probably be worth adding.
> That way if an issue is "open" it needs attention, "Under development"
> means someone is working on a solution, "pending" means someone is
> blocking the issue for more information, and "closed" means closed.
I like this. Open would mean that triage is still needed: reject and
close (or provisionally reject 'pending'), fix and close, or move to
'under developemnt.
> One thing to watch out for, Tennessee, is getting too specific. Like
> your "Request Approved" and "Specification Approved" just seems too
> heavy-handed to my tastes. Personally, I prefer to make sure the issue
> workflow to be somewhat simple so that people don't end up arguing over
> stuff like whether something has been specified well enough to have it
> set to "Spec Approved" even if someone else disagrees (which you know
> would happen).
The other problem with too many specifics is non-use. As it is, an
issue is sometimes closed with no resolution marked, so one has to
scroll down, possibly a long way, to see whether it was accepted or
rejected. (Is it possible to require a resolution when closing?)
Terry
More information about the Python-Dev
mailing list