Fedora bug triage - workflow proposal

[Christopher Brown]

On 15/01/2008, David Mansfield <fedora at dm.cobite.com> wrote:
>
> On Tue, 2008-01-15 at 17:01 +0000, Christopher Brown wrote:
> > On 15/01/2008, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> > > Jon Stanley wrote:
> > > >
> > > > 1)  Reporter files a bug report, it originates in NEW state
> > >
> > > Can we renamed this state to UNCONFIRMED?
> >
> > NEW or UNCONFIRMED, its six of one, half-a-dozen of the other...
> >
> > > > 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
> > >
> > > Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED
> > > frequently is assumed to be assuming ownership by the maintainers.
> >
> > ASSIGNED is easier and more understandable to people who have language
> > barriers to contend with.
> >
> > > > 4)  Once a developer has taken responsibility for a bug and is
> > > > actively working on it, the state transitions to ON_DEV.
> >
> > Sounds good.
> >
> > > If ASSIGNED is renamed to TRIAGED, then this state can be known as
> > > ASSIGNED instead.
> >
> > I'm keen not to get lost in arguing about the names of states. I think
> > all is fine as is - the issue here is workflow and what is best for
> > that.
> >
>
> I disagree and agree with the original poster, more or less, and I think
> names ARE important.  Do you name a variable tracking weight as 'height'
> in your program? No.  So names are important AND they should be
> understandable for non-native speakers.  I believe using ASSIGNED when
> it's _not_ assigned is a bad design choice, and using ON_DEV for
> ASSIGNED is also a bad choice, but I agree with you, TRIAGED is a bad
> choice for the WAITING_FOR_MANPOWER state...

In my triage work I use NEW, NEEDINFO and ASSIGNED for 95% of all open
bugs. Anything else I should not care about because it doesn't involve
me. I take NEW bugs and move them either to NEEDINFO or, if I think
there is enough for the maintainer to go on, I move it to ASSIGNED. It
is then up to the maintainer to resolve the bug in which ever way they
see fit.

NEW - A new bug
NEEDINFO - We need more info before we can proceed
ASSIGNED - Probably a bug, maintainer please review

Not difficult, pretty clear and no name changes required. Jon made the
point that the flipside to assigning bugs to maintainers is that an
equal if not greater number will be closed.

Essentially, the above is the workflow I'm using and for the past
three months it has worked very well.

Cheers

-- 
Christopher Brown

http://www.chruz.com