Review request: Nice-to-have bug process documentation proposal

[John Poelstra]

Adam Williamson said the following on 10/07/2010 01:24 PM Pacific Time:
>>> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed new page which covers the whole nice-to-have review process much as the above proposed page covers the blocker review process.

Thanks for doing all this Adam.

The "Nice-to-have bug principles" guidelines feels a little mushy and 
subjective to me, though after thinking about it for a while I can't 
propose anything better--you've done a good job putting some structure 
around what they might be.

And since they can't block the release they won't be able to cause that 
many problems.  I suppose if NTH bugs were to ever become a big 
distraction from addressing blocker bugs we could re-evaluate.

On the other hand it has taken us a *long* time to get to the place 
where we are today where churn in RC has been reduced to a bare minimum. 
  I still subscribe to the theory (realizing some in Fedora don't) that 
every additional change adds a level of risk of delaying the release. 
So my hope is that by formalizing the NTH we aren't encouraging an 
increased amount of churn.

I DO think this is an important section in the guidelines that will help 
cover this concern:

"In general, nice-to-have bugs are usually bugs for which an update is 
not an optimal solution, and for which the fix is reasonably small and 
testable (this consideration becomes progressively more important as a 
release nears, so bugs may be downgraded from nice-to-have status late 
in the release process if it transpires that the fix is complex and hard 
to test)."

Would it be overkill to put more explicit testing sign-off around NTH bugs?

John