[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora bug triage - workflow proposal

Jon Stanley wrote:

1)  Reporter files a bug report, it originates in NEW state

Can we renamed this state to UNCONFIRMED?

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
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.

4)  Once a developer has taken responsibility for a bug and is
actively working on it, the state transitions to ON_DEV.

If ASSIGNED is renamed to TRIAGED, then this state can be known as ASSIGNED instead.

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).

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.

Would a stock message be send to the bug reporters when closing bugs?

Would a separate Fedora page in bugzilla.redhat.com be useful?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]