[core-workflow] Tracker workflow proposal

[Antoine Pitrou]

Hi,

On lun., 2014-04-21 at 12:04 -0400, R. David Murray wrote:
> I drop 'compiler error', 'resource usage' and 'performance'.  All of
> these are bugs in the minds of the reporters, and classifying them
> separately in the 'type' field does not, as far as I can see, lead to
> any operational difference in the way the issue is treated.

But they are easily searchable that way, which is a big advantage (at
least for "resource usage" and "performance").

As for "compiler error", I find it interesting to categorize build-time
problems separately from runtime problems.

Note that these could become "components".

> I propose that we completely change the nature of this item.  I think we
> should make it a text field that is filled in by autocomplete like the
> nosy field can be, and that the value be any of the components listed
> in the experts file.  This would further respect how the experts have
> listed themselves in that file by autonosying those that are willing
> for that to happen.  The field should still be a multilink (that is,
> can contain more than one value).

Note that the UI then becomes less accessible to beginners (the current
list is readily displayed, having to start typing something is
intimidating when you don't know what to type).

> Patch Status
> ~~~~~~~~~~~~
> 
> This is a new set of fields that records information about the patch:
> 
>     unit test               
>     fix
>     documentation changes
>     news entry
>     what's new entry
>     commit message

Hmm, in principle I'd rather avoid us adding new fields (i.e.:
interaction is already complex enough).

> These fields allow us to represent all the parts that a patch must have
> to be complete, and they act as a checklist for making sure the parts
> are all there.  This is similar in intent to patchcheck, but since which
> pieces are needed is ultimately determined by a human, it is more accurate
> than that part of patchcheck and therefore more useful.

But is it *really* useful? You said you wanted additions to be
operational, not informational :-)

> The purpose of the 'stuck' tag is to label issues that we agree are
> real issues that we don't want to close as "won't fix", but that we
> can't for one reason or another currently move forward.  Operationally,
> stuck issues are either not displayed in work queues (see below) or are
> displayed at the end of the queue.

Is it a tag or a specific issue status, then?

>     new
>     needs information
>     needs decision
>     needs decision from committer
>     needs patch
>     needs review
>     needs patch update
>     needs commit review
>     closed/fixed
>     closed/wont fix
>     closed/duplicate
>     closed/insufficient information
>     closed/postponed
>     closed/not a bug
>     closed/third party

Up front, this looks like too much formalization (IMHO).

> A new issue can transition to:
> 
>     needs information                   user
>     needs decision                      user
>     needs patch                         triage
>     needs decision from committer       triage
>     closed                              triage, original reporter
>     needs review                        triage, if there is already a patch
>     needs commit review                 committer, if there is already a patch
> 
> That is, any user can indicate that more information is needed or
> request that triage decide whether to accept or reject the issue,
> but only triage can accept the issue as one that should be worked on
> (needs patch), or close it, or request a committer to make that decision.

Is there any reason to restrict actions by role like this? I don't think
we've had any significant amount of tracker abuse in the past.

(also, I'll remind you that we don't really have any official triagers,
instead letting everyone act as would-be triagers :-))

> We are waiting for more information from the original reporter, or
> from anyone else who manages to reproduce the problem.  If there is no
> additional activity for some period of time (one month?)  the issue is
> automatically moved to "closed/insufficient information".

I have never felt automatic closing was a good idea. A bug is a bug,
even if noone was able/willing to give more precise information. Also,
keeping a bug open can help other people find it later and bring
confirmation or information.

Regards

Antoine.