This document aims to set out the model by which the Parse Platform is governed and to provide specific insight into how we make decisions, give permissions and responsibility. We hope this aids transparency within the Parse Community and encourages the people who depend on Parse Server & its SDKs to get involved and improve the offering for all members of the community.
We loosely follow the Meritocratic Governance Model, we may deviate from this model as set out by this document and we encourage proposals to improve our methods of governance.
This is a meritocratic, consensus-based community project. Anyone with an interest is welcome to contribute and participate in decision making. This document describes how to participate and earn merit within the community.
Users consist of anyone who has a need for the project. They are very important members as without them the project wouldn't have a purpose.
We ask that users participate in the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):
- Evangelizing about the project (e.g. a link on a website and word-of-mouth awareness raising)
- Informing developers of strengths and weaknesses from a new user perspective
- Providing moral support (a ‘thank you’ goes a long way)
- Providing financial support (the software is open source, but its developers need to eat)
Some users who continue to engage with the project may become more involved and find themselves becoming contributors, as described in the next section.
Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms, as detailed in a separate document. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
In addition to their actions as users, contributors may also find themselves doing one or more of the following:
- Supporting new users (existing users are often the best people to support new users)
- Reporting bugs
- Identifying requirements
- Providing graphics and web design
- Programming
- Assisting with project infrastructure
- Writing documentation
- Fixing bugs
- Adding features
Contributors engage with the project through the issue tracker or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section).
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.
Anyone can become a committer; the only requirement is to 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 the project and have provided valuable contributions over time.
New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Committer voting is one of the few activities that takes place privately; to allow PMC members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published. 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 PMC Chair (see below) and will be anonymous and constructive in nature.
Nominees may decline their appointment as a committer. However, this is unusual, as the intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them into the project in any formal way.
Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources.
This does not mean that a committer is free to do what they want. In fact, committers have no more authority over the project than contributors. In almost all cases work should still be approved by other committers before being merged, to ensure the quality of the changes (we all make mistakes 😉).
The key differences between being a contributor and a committer is that committers have the ability to approve and merge pull requests.
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 PMC (see next section) in extreme circumstances.
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 member of the PMC, as described below.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.
The PMC has additional responsibilities over and above those of a committer, to ensure the project runs smoothly. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.
Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project’s private channels. These channels are 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 or planning.
The PMC Chair is a single individual, voted for by the PMC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the PMC casts a two-thirds majority vote to remove them.
The PMC Chair has no additional authority over other members of the PMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.
All participants in the community are encouraged to provide support for new users to encourage growth in 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 support from a qualified source.
Anyone can contribute to the project, regardless of skill, as there are many ways to contribute. For instance, a contributor might be active on the project issue tracker, or might supply patches. The various ways of contributing are described in more detail in a separate document.
Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC member. All non-sensitive project management discussion should take place publicly.
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 community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, submit a pull request or open a topic on discourse for proposals not related to a specific repository. This will prompt a review and, if necessary, a discussion of the idea.
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.
For lazy consensus to be effective, it is necessary to allow at least 72 hours 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.
Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. However, only project committers and/or PMC members (as defined above) have binding votes for the purposes of decision making.
A separate document describes in more detail how voting is conducted for this project.
