On 15/01/2008, David Mansfield <fedora@xxxxxxxxxxxxx> wrote: > > On Tue, 2008-01-15 at 17:01 +0000, Christopher Brown wrote: > > On 15/01/2008, Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
