Candidate Quality Election
The traditional release process in the Commons is as follows:
cut release candidate
announce release candidate on user and dev lists
wait a while to see if any issues are reported
VOTE on the release
cut release
This has many advantages. However, the actual release is never tested and the testing period is short. Components with large numbers of downstream users may like to consider an alternative system that encourages better testing of the actual release cut.
Candidate quality election follows a different pattern. A release is cut and announced as a release candidate. It is then VOTE'd to alpha, beta and full release quantity. Each stage is announced widely and users are encouraged to report any problems. If any issues emerge that must be addressed, a new release is created and the cycle starts again. Developers are recommended to VOTE +1 only if they have tested the release themselves.
The (idealized) process is as follows:
cut release
announce release candidate
promotion to alpha VOTE
announce alpha release
promotion to beta VOTE
announce beta release
promotion to full release VOTE
The actual release does not change, only the designation and name of the distributions.
This process is longer and more cumbersome but does offer better testing for the actual release.