[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