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. > > 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). These seemed to be quite useful in the run-up to F8 release. > I believe bugzilla folks are recommending the usage of flags over > blocker bugs. > > > 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. Yes, a large number of bugs are fire-and-forget where a fix is found but the reporter forgets to close the bug. > Would a stock message be send to the bug reporters when closing bugs? I'm currently using: As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. though I think it may need improvement. > Would a separate Fedora page in bugzilla.redhat.com be useful? One issue the triage team have at the moment is the ten different wiki pages all making mention of bug triaging. We aim to tackle this as a priority. A separate fedora bugzilla instance is under discussion but is obviously a mammoth task. Jon: ACK - I like all of the above. Do we have a procedure if a maintainer does not respond to a bug - there are a few... :) 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
