[core-workflow] Tracker workflow proposal

Tue Apr 22 06:46:42 CEST 2014

On Apr 21, 2014 8:49 PM, "R. David Murray" <rdmurray at bitdance.com> wrote:
>
> On Mon, 21 Apr 2014 18:53:41 +0200, Antoine Pitrou <antoine at python.org>
wrote:
> > 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".
>
> Yes, I think that would be good and desireable.
>

I think components are/were mostly used to indicate different dirs/packages
(e.g. Doc/, Modules/, Lib/, Liberty/test/, Lib/json/), but now also contain
Unicode, Windows, and even cross-build.

> > > 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).
>
> Well, the beginners wouldn't be setting it, someone more experienced
> would be setting.  When the beginner knows what to do with that field,
> they become one of the people who uses the 'uncollapsed' version of
> the UI and sets it.
>
> > > 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 :-)
>
> It would not break my heart to drop this :).  What it provides is a
> way to see at a glance what is missing, which in principle makes it
> possible for a new contributor to, say, add documentation to an otherwise
> complete patch.
>
> But that may well not be enough of an advantage to be worth it.
>
> Probably my main motivation for adding it, actually, was to make sure
> we get NEWS items and What's New items when appropriate, something we
> miss on a fairly regular basis.
>
> > > 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?
>
> A tag.  An issue can get stuck in any status in principle, though in
> practice I think it is most likely to happen in either 'needs patch'
> (ie: we don't know *how* to fix it) or one of the 'needs decision' states
> (we can't *decide* how to fix it).
>
> > >     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).
>
> It's not about formalization, though.  It's about making the list of
> bugs *manageable*.  The structure above is what provides the actionable
> work queues.  *That* is the point of the exercise, and not control :)
>
> > > 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.
>
> Well, at this stage probably not.  I can imagine us needing it if people
> (probably newcommers to the community) start pushing for 'needs patch'
> or 'commit review' before a bug is confirmed as a bug or before a
> patch is really ready, but we could change the permissions if and when
> that happened.  The permissions I proposed is mostly about scaleability,
> and while we are growing rapidly you are probably right that we aren't
> there yet.
>
> > (also, I'll remind you that we don't really have any official triagers,
> > instead letting everyone act as would-be triagers :-))
>
> Yes, except that many would-be triagers *can't* adjust the fields.  We do
> have a few (ex: I've given Developer privs to Berker Peksag and Jessica
> McKeller, to name two who are currently exercising the triage role only.
> Both of whom I hope will be committers before long :)
>
> Still, I don't myself have any objection to letting anybody do such
> updates and see how it goes (it will probably go just fine).
>
> > > 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.
>
> What if we made that another work queue in the triage dashboard,
> but issues would only appear there if they were more than N days old?
> In other words, someone would be prompted to make a decision to close
> the bug.
>

I usually set these as pending while asking for more info, so that they are
easy to find later. Closing them automatically could be OK. Of course we
won't close automatically issues with patches or some kind of progress,
even if slow.

> I don't think keeping bugs we can't reproduce open serves anyone.
> Our default search searches both open and closed bugs for a reason.
> Given the ability for anyone to reopen a bug, someone finding a closed
> "insufficient information" bug and reactivating it is easy.  However, if
> people feel strongly that they should be left open, it's not a big deal;
> we'd just leave 'needs information' as not being a work queue, and those
> open issues would get ignored (except in our total open issue count).
>
> --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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140422/85a01e9f/attachment.html>