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

Re: Fedora bug triage - workflow proposal

On Mon, 14 Jan 2008 23:46:36 -0500
jonstanley gmail com ("Jon Stanley") wrote:

> Well, it was a great session at FUDCon.  A lot came out of it, and I'm
> going to put some of them down here. The work flow suggested below I'd
> a FESco vote on, since it really affects you guys.  

Great. You might want to use (optional) 
and write up a page for FESCo to refer to for this. 

> This work flow was
> discussed between myself, John Poelstra, and Will Woods at the Sunday
> hackfest, and we agree that this is the correct way to move forward,
> however, we want community input and buy-in on this, since it has
> pretty far-reaching consequences.

Sorry I couldn't make it on sunday... had to catch a plane. ;) 

> Here is the lifecycle of a bug:

Looks great to me. 

> Note that at any step of the above process, the maintainer can "fast
> track" the bug, and change it to ASSIGNED.  The triage team is not
> going to look at bugs that are not in NEW or NEEDINFO state.  On the

What if the bug is put in NEEDINFO(maintainer) by the reporter?
Ie, they have provided info or need to ask the maintainer about
something, but the maintainer isn't responding? Are those closed? 
They probibly shouldn't be... 

> flip side of that, it is not a maintainer's responsibility to look at
> bugs that are in NEW any longer.  They can focus their energy on the
> bugs that are ASSIGNED to them.
> Also, maintainers should not be allowed to set priority on bugs.
> 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'm not sure how usefull this will be. Maintainers pretty much ignore
priority now, as reporter (or any package maintainer) can set it... 

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

What about the above case of NEEDINFO(maintainer)? 

> I think that's all that I have to say on this topic right now, let me
> know if I'm missing anything or this is complete hogwash :)

I think this is great! ;) 
I'd be happy to help with triage... 

> -Jon


Attachment: signature.asc
Description: PGP signature

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