Fedora bug triage - workflow proposal

[Hans de Goede]

Jon Stanley wrote:
> Well, it was a great session at FUDCon.  A lot came out of it, and I'm
> going to put some of them down here. The work flow suggested below I'd
> a FESco vote on, since it really affects you guys.  This work flow was
> discussed between myself, John Poelstra, and Will Woods at the Sunday
> hackfest, and we agree that this is the correct way to move forward,
> however, we want community input and buy-in on this, since it has
> pretty far-reaching consequences.
> 
> Here is the lifecycle of a bug:
> 
> 1)  Reporter files a bug report, it originates in NEW state
> 2)  Triage team looks at bug report, determines if dupe or
> insufficient information exists to solve it. If there is not enough
> information in the bug, then triage team puts the bug in NEEDINFO.  As
> you will see below, this state has a finite life cycle associated with
> it.
> 3)  Assuming bug survives through the triage team, it changes state to
> ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as
> appropriate).  Note that per the definition[1], ASSIGNED does not mean
> that someone has actually agreed to take action, simply that the issue
> is well defined and triaged accordingly
> 4)  Once a developer has taken responsibility for a bug and is
> actively working on it, the state transitions to ON_DEV.
> 5)  Once an update addressing a bug exists in Bodhi, and is pushed to
> updates-testing, the status automatically transitions to ON_QA
> 6)  When the update is pushed to stable, Bodhi optionally closes the
> bug automatically.  If the update does not auto-close the bug, it
> transitions to NEEDINFO_REPORTER, with a comment explaining that the
> update has been pushed to stable, and to update and test in the new
> release.
> 
> Note that at any step of the above process, the maintainer can "fast
> track" the bug, and change it to ASSIGNED.  The triage team is not
> going to look at bugs that are not in NEW or NEEDINFO state.  On the
> flip side of that, it is not a maintainer's responsibility to look at
> bugs that are in NEW any longer.  They can focus their energy on the
> bugs that are ASSIGNED to them.
> 
> Also, maintainers should not be allowed to set priority on bugs.
> Setting severity is fine.  Only QA or releng should set priorities.
> This allows us to look at things in a sane manner (which is impossible
> now since severity and priority fields come from /dev/urandom
> seemingly), and possibly lessen the reliance on blocker bugs (though
> blockers are useful in their own right, so don't think that we are
> going to eliminate them any time soon).
> 
> It was also decided that when a bug is in NEEDINFO for one month, it
> will be closed.  Maintainers would need to realize that putting a bug
> in NEEDINFO is putting it on the fast track for closure.
> 
> I think that's all that I have to say on this topic right now, let me
> know if I'm missing anything or this is complete hogwash :)
> 

Sounds like an excellent plan to me, lets implement this asap!

I would like to point out though that this solves only part of the problem. An 
important part, but I wonder if anything was discussed regarding the other 
part, unresponsive maintainers. I often see perfectly fine bugs (well 
described, reproducable) with 0 maintainer attention. I know we are all human 
but most of the time it are always the same maintainers who are unresponsive, 
and they seem to simply be unresponsive to any bugs. So its not that they are 
prioritizing, they seem to be simply ignoring bugzilla mail.

I know we have the awol procedure for this, but often they are not awol, they 
are productive contributers, who's strengths lay outside of bugfixing.

Thus I would like to see a bug fixing team, to complement the bug triage team 
who's task it will be to actually fix bugs which have moved to the assigned state.

Now primarily this is the task of the maintainer, but sometimes leaving this up 
to the maintainer seems to not work one way or the other. So I guess it would 
be good to have a fallback bugfixing team, and maybe a way for packagers, who 
for example lack the coding skills, to subscribe to this team's services. As 
always I'll put my code where my mouth is and I will gladly join such a team if 
formed.

Regards,

Hans