| --- |
| title: "Glossary" |
| permalink: /:path/:basename/index.html |
| layout: page |
| toc: true |
| --- |
| |
| |
| |
| In the free and open source software communities, meritocracy is one of the 3 |
| main governance models in use and is likely the most popular, powerful, and |
| successful. However, there is still, at times, confusion over how exactly this |
| model works. |
| |
| First and foremost, the basic tenet behind meritocracy is that people gain |
| merit by their actions and activities within the community. What actually |
| comprises that merit is determined by the pre-existing community itself, and so |
| there exists an internal, stabilizing feedback system that prevents a healthy |
| meritocracy from going askew. This basis of "what is merit" and "how one earns |
| it" is self-defined and known within the community and can, and does, vary from |
| community and project. For example, one FOSS project/community may value simple |
| coding capability above all, and thus heavy-coders will gain merit quickly, |
| whether they do so as volunteers or are paid to do so, and whether they work |
| well with others or not. Other communities value a healthy balance of coding |
| skills with consensus-based collaboration skills, whereas others also include |
| the individual's personal stake in the project (how much they are personally |
| involved and invested). |
| |
| As the above shows, a meritocracy is not, therefore, a democracy proper but a |
| pseudo-republic. The wants and desires of the community are weighed in the |
| atmosphere of merit that enables access and control. |
| |
| ## Consensus decision making |
| |
| One practice of meritocracy is the consensus-based decision model. From |
| http://en.wikipedia.org/wiki/Consensus_decision-making, "Consensus |
| decision-making is a group decision making process that seeks the consent of |
| all participants." In practice, it is different from a majority-vote-wins |
| approach. In the CentOS Project a discussion toward a decision follows this |
| process: |
| |
| 1. A proposal is put forth and a check for consensus is made. |
| 1. Consensus is signified through a +1 vote. |
| 1. A check is made for any dissent on the proposal. |
| 1. Reservations? State reservation, sometimes with a '-1' signifier |
| 1. Reservations about the proposal are worked through, seeking consensus to resolve the reservations. |
| 1. A reservation is not a vote against the proposal, but may turn into a vote against if unresolved. It is often expressed with an initial -1 vote to indicate reservations and concerns. This indicates there is still discussion to be had. |
| 1. Stand aside? No comment, or state concerns without a -1 reservation; sometimes the '-0' signifier is used. |
| 1. This option allows a member to have issues with the proposal without choosing to block the proposal, by instead standing aside with a +/-0 vote. |
| 1. The stated concerns may influence other people to have or release reservations. |
| 1. Block? Vote '-1' with reasons for the block. |
| 1. This is a complete block on a proposal, refusing to let it pass. A block is a -1 vote and must be accompanied with substantive arguments that are rooted in the merit criteria of the Project -- protecting the community, the upstream, technical reasons, and so forth. |
| |
| Block (-1) votes used as a veto are typically used only when consensus cannot otherwise be met, and are effectively a veto that any sitting Board member can utilize with sufficient substantiation. |
| |