Contributor Model
Welcome to the YUI project! We look forward to your involvement and participation. We try to keep everything as simple as possible, but we have a few ground rules to help us all work together. Normally these guidelines are not needed -- the project just gets on with its day-to-day operation -- but they enable everyone to understand how the project operates, what to expect, and, most importantly, how to get involved!
This is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design and participate in technical decisions. This document describes how that participation takes place and how to set about earning merit within the project community.
Users are community members who have a need for the project. Anyone can be a User; there are no special requirements. Common User contributions include evangelizing the project (e.g., display a link on a website and raise awareness through word-of-mouth), informing developers of strengths and weaknesses from a new user perspective, or providing moral support (a "thank you" goes a long way).
Users who continue to engage with the project and its community will often become more and more involved. Such Users may find themselves becoming Contributors, as described in the next section.
###2.2. Contributors Contributors are community members who contribute in concrete ways to the project, most often in the form of code and/or documentation. Anyone can become a Contributor, and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements, and no selection process.
Contributors engage with the project through the YUILibrary Issue Tracker, YUILibrary Forum, and the Contributor Mailing List. They submit changes via pull requests which will be considered for inclusion in the project by existing Committers (see next section). The YUILibrary Forum or #yui IRC channel on Freenode are the most appropriate places to ask for help when making that first contribution.
All YUI Contributors are required to sign the YUI Contributor License Agreement. Why? The CLA ensures that everyone who submits a work of authorship to the YUI project is contributing work that is their own or for which they can authoritatively speak. This protects the tens of thousands of developers who use YUI, all of whom rely on YUI's BSD license to appropriately cover their use of the YUI code & its other developer tools.
As Contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership by an existing Committer.
Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committers are given push access to the project's GitHub repo and must abide by the project's Contribution Standards, including milestones such as feature complete and code freeze.
While committership indicates a valued member of the community who has demonstrated a healthy respect for the project's aims and objectives, their work continues to be reviewed by Reviewers (see below) before acceptance in an official release.
To become a Committer, one must have shown a willingness and ability to participate in the project as a team player. Typically, a potential Committer will need to show that they have an understanding of and alignment with the project, its objectives, and its strategy. They will also have provided valuable contributions to the project over a period of time and, specifically, a minimum of 10 qualifying pull requests. What's a qualifying pull request? One that carries significant technical weight and requires little effort to accept because it’s well documented and tested.
New Committers can be nominated by any existing Committer. Once they have been nominated, there will be a vote by the Reviewers (see below). Committer voting is one of the few activities that takes place on the project's private management list. Once the vote has been held, the aggregated voting results are published on the Contributor Mailing List. The nominee is entitled to request an explanation of any 'no' votes against them, regardless of the outcome of the vote. This explanation will be provided by the Reviewers (see below) and will be anonymous and constructive in nature.
It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Reviewers (see next section) in extreme circumstances. However, under normal circumstances committership exists for as long as the Committer wishes to continue engaging with the project.
A Committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a Reviewer, described below.
Reviewers are individuals identified as "project admins" for the project on GitHub. Reviewers have additional responsibilities over and above those of a Committer. These responsibilities ensure the smooth running of the project. Reviewers are expected to review code contributions, approve changes to this document, and manage the copyrights within the project outputs.
Reviewers' contributions can be reviewed by other Reviewers, but this is not explicitly required. Reviewers do not have significant authority over other members of the community, although it is the Reviewers that vote on new Committers. They also make decisions when community consensus cannot be reached. In addition, the Reviewers have access to the project's private Reviewers' Mailing List and its archives. This list is used for sensitive issues, such as votes for new Committers and legal matters that cannot be discussed in public. It is never used for project management, planning, or discussion of technical matters.
A Committer is invited to become a Reviewer by existing Reviewers. An existing Committer may considered for Reviewer status only after they have submitted 50 qualifying pull requests of technical significance that have been accepted without significant rework into the project. A nomination will result in discussion and then a vote by the existing Reviewers.
All participants in the community are encouraged to provide support for new Users as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A User requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a Contributor might be active on the YUILibrary Forum and Issue Tracker, or might supply patches via pull requests. The YUILibrary Forum is the most appropriate place for a Contributor to ask for help when making their first contribution.
Contributors should review YUI’s Contribution Standards and get familiar with the project’s Developer Workflow. See Contribute to YUI and Contribute Code to YUI for detailed information.
We expect our community to be self-regulating in a friendly, cooperative, and collaborative manner. We are all here to learn from one another, and disrespectful conduct is unnecessary and unacceptable.
Technical discussions are conducted on GitHub, the bug tracker, and the Contributor Mailing List. The Forum should mainly be used for technical support. Occasionally, sensitive discussions may occur on the private Reviewers' Mailing List.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
Decision making typically involves the following steps:
- Proposal
- Discussion
- Vote (if consensus is not reached through discussion)
- Decision
Any voting community member (Contributor, Committer, or Reviewer) can make a technical proposal for consideration by the community. In order to initiate a discussion about a new idea, they should submit a pull request on GitHub or post to the Contributor Mailing List. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.
In general, as long as nobody explicitly opposes a proposal or patch, it is recognized as having the support of the community. This is called lazy consensus -- that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal. Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.
For lazy consensus to be effective, it is necessary to allow at least 72 hours (excluding weekends and holidays) before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest, and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.
If a Reviewer approves a proposal, any Committer or Reviewer may choose to waive the 72 hour waiting period and merge the code in directly.
Not all technical decisions can be made using lazy consensus. Larger issues such as those that may affect the strategic direction of the project must gain explicit approval in the form of a vote. This section describes how a vote is conducted. Section 5.4 discusses when a vote is needed.
All Contributors, Committers, and Reviewers have a vote. The project encourages open discussions prior to voting. However, only Committers and Reviewers have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of all community members are considered. While only Committers and Reviewers have a binding vote, a well-justified “-1” from a Contributor must be considered by the community, and if appropriate, supported by a binding “-1”.
If a formal vote on a proposal is called (signaled simply by sending an email to the Contributor Mailing List with “[VOTE]” in the subject line), all participants may express an opinion and vote. They do this by replying to the original “[VOTE]” email:
- +1: meaning “yes”, “agree”: the voter may also be willing to help bring about the proposed action,
- -1: meaning “no”, “disagree”: opposes the action’s going forward. The voter should propose an alternative action to address the issue (or a justification for not addressing the issue)
To abstain from the vote, participants simply do not respond to the email.
A “-1” can also indicate a veto, depending on the type of vote and who is using it. Someone without a binding vote cannot veto a proposal, so in their case a “-1” would simply indicate an objection.
When a “[VOTE]” receives a “-1”, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding veto), or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the Reviewers will decide the forward course of action.
In summary:
- Those who don't agree with the proposal should vote “-1” and offer a counter-proposal.
- Those who agree should vote “+1”; it is hoped they will actively assist in implementing the proposal.
Different actions require different types of approval, ranging from lazy consensus to a majority decision by the Reviewers. These are summarised in the table below. The section after the table describes which type of approval should be used in common situations.
| Type | Description | Duration |
| Lazy consensus | An action with lazy consensus is implicitly allowed unless a binding -1 vote is received. | 72 hours (excluding weekends and holidays) |
| Lazy majority | A lazy majority vote requires more binding +1 votes than binding -1 votes. | 72 hours (excluding weekends and holidays) |
| Consensus approval | Consensus approval requires three binding +1 votes and no binding -1 votes. | 72 hours (excluding weekends and holidays) |
| Unanimous consensus | All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1). | 120 hours (excluding weekends and holidays) |
| 2/3 majority | Some strategic actions require a 2/3 majority of Reviewers; in addition, 2/3 of the binding votes cast must be +1. Such actions typically affect the foundation of the project (e.g., adopting a new codebase to replace an existing product). | 120 hours (excluding weekends and holidays) |
Every effort is made to allow the majority of decisions to be taken through discussion and lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. However, some activities require a more formal approval process in order to ensure fully transparent decision making. The table below describes some of the actions that will require a vote. It also identifies which type of vote should be called.
| Action | Description | Approval type |
| Documentation or tests | Fixing typos, adding unit tests. | None required, unless at the request of the submitter |
| Code change | Pull request or other code-related proposal | Lazy consensus, or explicit approval with waiver of the waiting period by a Reviewer |
| Architectural change | Major change with large impact | 2/3 majority of the Reviewers |
| New Committer | A new Committer has been proposed. | Consensus approval of the Reviewers |
| New Reviewer | A new Reviewer has been proposed. | Consensus approval of the Reviewers |
| Committer removal | When removal of commit privileges is sought. | Unanimous consensus of the Reviewers |
| Reviewer removal | When removal of Reviewer membership is sought. | Unanimous consensus of the Reviewer community |
This project is your project. The point of this document is to grow the project by enabling, facilitating, and securing contributions in a manner that satisfies everyone. Let us know through the YUILibrary Forum if you have any comments!
This work derivative of Meritocratic Governance Model by Ross Gardler, Gabriel Hanganu at University of Oxford.
This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License.
2