[core-workflow] tracker 'resolution'

[Ezio Melotti]

Hi,

On Apr 19, 2014 5:59 AM, "R. David Murray" <rdmurray at 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 at 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