Fedora bug workflow - process change

[Matej Cepl]

On 2008-02-25, 20:05 GMT, Jon Stanley wrote:
> The ASSIGNED state is a state that has a new meaning - it used 
> to mean that the bug was actually assigned to a person. 
> Instead, it now means that the bug is capable of being worked 
> on by a maintainer - i.e. the triage team believes that this is 
> a complete, actionable bug - i.e.  with a stack trace for 
> a crasher, various log files for other components, complete AVC 
> message for SELinux stuff, etc.

a) I totally agree not to require retooling — Red Hat Bugzilla 
   maintainers are totally buzzy with upgrading to Bugzilla 3.2
   (yay!!!) but Red Hat BZ is so heavily modified that this is
   crazy amount of work.

b) ASSIGNED state is really ambiguous, but its definition is not 
   what is important about it (and believe me, as a former
   lawyer, I like heated discussions about definitions ;-)). To
   make further discussion more understandable I will venture
   with these definitions of ASSIGNED, but I repeat this is not
   what's important, the further discussion is.

   So, ASSIGNED could mean:

   1) The bug has been triaged, and the triager believe that
      there is nothing she can do about it and further decisions
      about the bug have to be done by developers. (Further
      discussion what this actually means would be endless, so 
      I will skip it here).
   2) The bug has been put to the sack of particular developer(s)
      and he will (sometime) work on it.
   3) The bug is actively being worked on by a particular 
      developer(s).

My point is that in this discussion many people seem to confuse 
2) and 3). I don't want to indulge here in the discussion whether
there should be a special state of the bug to distinguish between 
these two, because I believe that THIS IS TOTALLY OUTSIDE OF THE 
WORK OF BUG TRIAGERS. Our only job is to get bug to the state 1) 
(or 2) at the best -- see below), but we have no business to tell 
developers what they should do.

It is very important IMHO to actively understand that we are here 
just as servants of developers (using so strong words to make an 
emphasis), the only purpose of our work is that davej, ajax et 
al. don't have to deal with stupid stuff like obsolete NEEDINFOs, 
but we are certainly not in the position to decide what davej 
should do and what are his priorities (actually we may end up 
setting the priority/severity field sometime, but currently it is 
useless and impossible, and it is not what I mean here).

Less important but still IMHO interesting and relevant to our 
discussion is the distinction between 1) and 2). For me 
personally, while working on my Xorg bugs, this distinction is 
not particularly relevant (and bugs I triage should end in the 
state 2)), because I know from discussion with developers what 
kind of bugs each of them expects, and of course whenever in 
doubts what to do with a particular bug I could ask on IRC.

Which leads me to the point, that for bug triager to be excellent 
it is crucially important to be part of the team of developers 
for the particular set of components.

Well, let me back off a little bit. We are here talking probably 
about two types of bug triaging. It is certainly useful when 
somebody just runs through kernel bugs and deals with old 
NEEDINFOs, never to be seen again.

But there is a higher position waiting for each of us -- to be 
part of the team who actually actively develops Fedora, even 
though you cannot write a line in C if it would save your life.  
And that's where it begins to be fun and really interesting.

Does it make a sense?

Matej