Re: Basic questions about the triage process

[Eli Zaretskii]

> From: Andrew Hyatt <address@hidden>
> Date: Tue, 29 Dec 2015 00:40:08 -0500
> 
> I've put together my notes into a file I stuck in the admin section.

Thanks.  A few comments below.

> +* The what and why of bug triage
> +
> +Bugs have to be regularly looked at and acted upon.  Not all bugs are
> +critical, but at the least, each bug needs to be regularly re-reviewed
> +to make sure it is still reproducible.  A large backlog of bugs is
> +disheartening to the developers, and a culture of ignoring bugs is
> +harmful to users, who expect software that works.

This paragraph is probably better to move to CONTRIBUTE.  It should
point to this file, which in turn should describe only the triage
itself, not its importance.

> +The goal of this triage is to prune down the list of old bugs, closing
> +the ones that are not reproducible on the current release.

I think triage is more than that: it should also strive to classify
the bugs according to their importance.

> +  1. To start, enter debbugs mode (either debbugs-gnu or debbugs-org), and
> +     accept the default list option of bugs that have severity serious,
> +     important, or normal.  
> +  2. This will also show closed bugs that have yet to be archived.  You can
> +     filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress).

Triage can be done via a Web browser as well.  I suggest to mention
debbugs-gnu as one possibility, perhaps the preferred one, but not the
only one.

> +  3. For each bug, do the following:
> +     - Read the mail thread for the bug. Find out if anyone has been able to
> +       reproduce this on the current release.
> +     - If someone has been able to, then your work is finished for this bug.

Again, having the bug reproducible is not the end of triage, at least
not in general.  It is a good idea to use your judgment to decide
whether the bug is really a bug (and if so, how important it is), a
request for a new feature, or simply a rant.  debbugs.gnu.org supports
tags for recording the results of this process; it would be good if at
least some bugs got tagged accordingly as result of the triage.

> +     - If you can reproduce, then reply on the thread (either on the original
> +       message, or anywhere you find appropriate) that you can reproduce 
> this on
> +       the current release.

Here, I'd suggest to request adding relevant details.  Sometimes bug
reports don't provide backtraces, or don't even describe the recipe in
sufficient detail.  If the triage supplies these details, let alone if
you can come up with a simpler reproducer, adding this information
will be of great value to those who will come after you to try
resolving the bug.

Also, if the description isn't detailed enough, it might be a good
idea to ask for more detailed description, because the stuff that was
left out might be the reason for not being able to reproduce the bug
in the first place.

> +     - If you can't reproduce, but the bug is newer than 2 years old, state 
> that
> +       you can't reproduce it on the current release, ask if they can try 
> again
> +       against the current release.

There's a tag for that, I believe.

> +  4. Your changes will take some time to take effect. After a period of 
> minutes
> +     to hours, you will get a mail telling you the control message has been
> +     processed. At this point, you and everyone else can see your changes.

That mail can also say there were errors, something to mention here, I
think.

Thanks again for working on this (and on the triage itself).