[core-workflow] tracker 'resolution'
R. David Murray
rdmurray at bitdance.com
Sat Apr 19 04:59:41 CEST 2014
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
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.
The ordering is currently mostly-alphabetical, I picked an ordering
that feels "logical" to me, but I'm not really attached to the ordering.
--David
More information about the core-workflow
mailing list