Hi, On Apr 19, 2014 5:59 AM, "R. David Murray" <rdmurray@bitdance.com> wrote:
I had a fair amount of time to think during my drive home from PyCon. I have some preliminary thoughts about ticket workflow and ways we can improve it. I'll try to write it up this weekend to act as a conversation starter.
In the meantime, I'd like to put forth a small proposal with regards to one specific thing in the current tracker interface. Currently for resolution we have:
duplicate fixed not a bug later out of date postponed rejected remind wont fix works for me 3rd party
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
IIUC this is what you are doing: duplicate = duplicate not a bug = not a bug + rejected works for me = works for me (+ out of date?) fixed = fixed postponed = later + remind + postponed (+ out of date?) won't fix = wont fix 3rd party = 3rd party This seems a reasonable request to me. I've been trying to simplify the interface of the tracker and remove non-essential elements, and this would be a good step in that direction. The next step could be "merging" this with the "closed" status so that you select the resolution once while you mark the issue as closed (or possible pending).
You may or may not recall that we used to have a resolution 'accepted', where 'accepted' was "supposed" to be for enhancements that were committed. It tended to be an attractive nuisance, though, since people would set it when they thought the bug *should* be fixed rather than when an enhancement was committed. (There is a sense in which it is indeed valuable to be able to say that, but I'll suggest a way to deal with that in my larger brain dump; it doesn't belong in the 'resolution' field :).
'rejected' isn't really an attractive nuisance, but it doesn't get applied only to enhancements. Sometimes it is applied to proposed "bug" fixes. So, the distinction between "won't fix" and "rejected" is not clear, and thus has little utility. Now, we *could* go through and "fix" the metadata if we actually wanted to use that distinction for something, but I doubt that we do. If you are analyzing tracker data, you can always check if the issue was an enhancement or not. So I propose that we drop 'rejected' and just close rejected enhancements as "won't fix". (After all, we often only half-jokingly say that enhancement requests are "API bugs".)
For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them.
While doing these changes we should keep in mind what are all those fields useful for. I can think of two main use cases: 1) searching/filtering issues (both for finding specific issues or for analyzing tracker data); 2) informing users about the current situation of the issue; In general I don't think anyone needs such a fine-grained filtering (have you ever looked for "postponed" issues or wanted to know how many "later" issues there are?), and the rationale for closing the issue could be detailed in the message, so I'm +1 on the change you suggest.
The ordering is currently mostly-alphabetical, I picked an ordering that feels "logical" to me, but I'm not really attached to the ordering.
Remember that there is also https://wiki.python.org/moin/DesiredTrackerFeatures which contain discussions and ideas about possible improvements to the interface. Best Regards, Ezio Melotti
--David _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct