Desktop Team Triage Policy

Matěj Cepl, 2007-10-30

Informational material for purposes of a discussion on fedora-advisory-list—not finished and under review!

The purpose of this document is to stabilize the current policy of handling bugs on the triaging side of the pipeline (i.e., I won't deal here with MODIFIED, ON_QA and similar states of bugs; if needed, this document certainly can be extended for dealing with whole pipeline), so basically at the moment a bug is marked as ASSIGNED, it falls out of the scope of this document.

The structure of this document follows a bug from its entering our bugzilla to either the moment the bug is ASSIGNED to particular developer or until it is CLOSED for some reason other than that it is resolved.


Reporter files a new bug against some particular component and the bug gets automatically assigned to the default owner of the component.

Practically a bug in this state means that the bug hasn't been triaged and that the people who are responsible for triaging bugs should deal with it. In the ideal state (i.e., there are enough triagers available), developers shouldn't touch such bugs at all. Of course, it doesn't mean that developers are not allowed to assign a bug to themselves, thus taking it out of the dirty hands of bug triagers -- the whole point of bug triage is to make bugs digestable by developers, and when a developer decides that he knows enough about a bug and wants to take it himself, there is no reason in the world to stop him from doing so. The only thing to be emphasized is that when developer takes over a bug, he should switch status of the bug to ASSIGNED and then he is on his own.

Because bug 234261 has been fixed (yay!) we can finally say that the bug is NEW as long as it has been not triaged and only then (manually) will be switched to ASSIGNED.

[unrelated discussion about internal organization of bugs and assigning them to different developers was snipped out here]

Possible transitions from NEW state

Dark magic of NEEDINFOing

Although I claimed that NEEDINFO is not valid transition state, it doesn't mean by any means that NEEDINFO is not important, or that it shouldn't be used. Just to the contrary, for the bug triager it is the most important state that the bug under her control could be in.

The main reason why I don't want to talk about NEEDINFO as another transition state is to emphasize that the bug in NEEDINFO state doesn't leave bug triagers' control -- it should be kept under control and if it is not alive enough, it should be closed (more about that later).

Putting a bug into NEEDINFO will get it into something I would call The Iron Grip of NEEDINFO. The point is that one of the bug triager's regular tasks is to run daily a query old NEEDINFO which finds all bugs in the NEEDINFO status in (currently) Xorg, Gecko, and Evolution super-components which were not changed in the last 30 days. Then his duty is to do something about each of this bug:

The point is obviously that something MUST change in the bug, so that the bug won't show up next day in the same query. Of course, if the reporter gives reasonable explanation for not being able to answer immediately, the bug triager should be free to allow him to do that, but always in one month installments with pinging him at least every month. By keeping one month as rigorous schedule for looking at every NEEDINFO bug we can be sure that the bug doesn't slip out of control.

The question is how many times a bug can show up in the query (i.e., how many months it can get saved from being closed). And the answer is very vague. Usually, the bug gets at least once a comment which explitly says, that if the answer isn't provided within a month, it will be closed as CLOSED/INSUFFICIENT_DATA, but judgement when the bowl breaks is not rigid. If there are clear signs that the bug is useless and the answer won't come or it will be useless (e.g., a year old bug without a comment in the last ten months, in a component which was drastically changed in the last year), then probably even no reminder need to be sent. However, bugs in RHEL-like distribution with grave impact may get multiple reminders, direct email/IRC can be tried, before the triager's patience will run out.

This iron grip of NEEDINFO is so useful in eliminating incovenient bugs, that the basic strategy of dealing with any problematic bug for any reason, is to convert it into NEEDINFO state, and then it will be dealt with automatically. Flip side of this is that every developer should be aware that a bug in NEEDINFO state is on the slippery slope towards being closed in the limited amount of time. (Of course, developers decisions are sacred, so if needed comment Please, don't close ever. could be added to avoid closing.)

[Discussion of RHEL and RHEL-like bugs omitted.]

One important aspect of NEEDINFO is that it is easy to create standardized responses. There are many standard comments for switching a bug to NEEDINFO state. This is the list:

Bugs retention policy

(currently this policy so far applies only to Xorg, Evolution, and Gecko & co. bugs)

Although we may like to keep bugs open for as long as they are solved, Red Hat operates only with limited resources (which is especially true about the desktop team), and so we have to limit the number of bugs which are currently open (and where we implicitly promise that some development will be done). Therefore old bugs have to be removed out of the way.