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.

NEW

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 delete: <a href="#nonRHEL"> RHEL-like delete: </a> 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.)

A controversial issue is closing delete: <em> [Discussion of RHEL and RHEL-like bugs delete: </em> for inactivity. Certainly the general rules holds, that RHEL bugs shouldn't be close due to inactivity ever. delete: <a name="nonRHEL" id= "nonRHEL"> Except there are many bugs in bugzilla assigned to RHEL product, which are not really RHEL bugs. delete: </a> Many of them were reported by Red Hat employees while testing Beta versions of RHEL. Of course, if the bug hits our internal reporter, than probably it will hit our customer as well, so such bugs should get a high level of scrutiny. Another members of this group are the ones which are actually delete: <a href= "http://www.centos.org"> CentOS delete: </a> bugs (although for the sake of both distributions, reporters should be asked to file a bug in delete: <a href="http://bugs.centos.org/"> CentOS bugzilla delete: </a> ). delete: </p> delete: <p> Nevertheless, I believe that even such bug doesn't have to be treated with the same level of rigidity as another bug, which comes through IssueTracker. If the internal beta testers are unresponsive to delete: <var> NEEDINFO delete: </var> , and the best effort to communicate with them were used (that includes emails and pinging them on IRC; but remember Red Hat is not only engineering team and not everybody with delete: <code> @redhat.com delete: </code> in her email address uses IRC), then the bug should closed without any mercy. delete: </p> delete: <p> Related to that, but much less important is the question whether the reporter of bug against the RHEL product has delete: <em> a valid entitlement for the official Red Hat support delete: </em> and so whether the bug shouldn't be filed in Issue Tracker instead. The standard message for redirecting reporter to IT is: delete: </p> delete: <blockquote> delete: <p class="code"> For official Red Hat Enterprise Linux support, please log into the Red Hat support website at http://www.redhat.com/support and file a support ticket, or alternatively contact Red Hat Global Support Services at 1-888-RED-HAT1 to speak directly with a support associate and escalate an issue. delete: </p> delete: </blockquote> delete: <p> The point of such message is that although certainly nobody will remove a RHEL bug from bugzilla only because the reporter hasn't filed it in IssueTracker, they will get lower priority, and the bug is suspectible to delete: <var> WONTFIX delete: </var> , or UPSTREAMing. Of course, it should be noted (and even to the reporters themselves) that their bug won't be closed only because they use CentOS, but their bug will be treated with the priority of Fedora 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.