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... David -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
