Eli Zaretskii writes: >> From: Andrew Hyatt >> 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. OK, I've done so (see the modified patch I've attached). This probably needs a bit more work since we want to talk about more kinds of triage as well (notably the triaging of new bugs), eventually. > >> +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. Yes, but isn't that more about triaging new bugs? I'm not writing about that yet - but if someone tells me how to triage new bugs I'm happy to write it up. > >> + 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. Done. > >> + 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. Again, I think this right, but for new bug triage which I haven't written up yet. For the bug backlog, I'm assuming someone has already taken a pass at each bug. > >> + - 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. Done (although I split this up into two parts - one new bullet point, another as part of the text on what to do if you can reproduce the issue). > >> + - 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. We can just use the "unreproducible" tag. Sounds like a good idea. I'll add that. > >> + 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. Mentioned, but I'm a bit at a loss on what to say if there were errors. > > Thanks again for working on this (and on the triage itself). No problem. I've also removed, by popular demand, the distinction between pre-and-post 2 years old. Now we'll always just ask first. I've also fixed a few spelling and grammar errors.