|
2010-12-14
, 11:28
|
Posts: 263 |
Thanked: 679 times |
Joined on Apr 2008
@ Lyon, France
|
#12
|
|
2010-12-14
, 13:58
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#13
|
I personally disagree with the "blocker" list on 2 points: not all crashers or incomplete features should be blockers, IMHO - if an application crashes when some unusual set of circumstances happens, then it should still get promoted; and I don't think we should be policing "missing announced features".
|
2010-12-14
, 14:05
|
Posts: 263 |
Thanked: 679 times |
Joined on Apr 2008
@ Lyon, France
|
#14
|
Of course, there's a difference between clarifying language/fixing typos and changing the meaning of the QA criteria used for testing apps. One of them can be done by anybody, the other requires consensus.
The Following User Says Thank You to dneary For This Useful Post: | ||
A "blocker" is "a bug which blocks the package from being promoted to Extras" - as such, only serious problems should block packages. These problems should cover filesystem corruption & systemic overuse, excessive power consumption in normal operation, legal issues, lack of a community reporting mechanism, and any non-edge-case crasher bugs.
I personally disagree with the "blocker" list on 2 points: not all crashers or incomplete features should be blockers, IMHO - if an application crashes when some unusual set of circumstances happens, then it should still get promoted; and I don't think we should be policing "missing announced features".
So if you would like to update the lead-in paragraph to elaborate on what is meant by a blocker, then I would be delighted! Just log in, click on the edit link beside the paragraph, and update. Everything is version controlled, so you have a safety net to roll back if you are unhappy with the result.
Good luck!
Dave.