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
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