This document provides the governance guidelines under which the PlatON open source project operates. It defines roles and responsibilities, who can vote, how voting worked, how conflicts are resolved, etc. PlatON is supported and promoted by the LatticeX Foundation, and is governed by the existing LatticeX Foundation Charter (see the LatticeX Foundation website for details). This guide supplements the LatticeX Foundation Charter, and will provide everyone with a clear understanding of how the PlatON program works.
PlatON Community-Based Development & Governance Guideline (First Draft)
Overview
Our goal is to make PlatON an open source project that is community-driven, open development, and sustainable.
PlatON will be governed by a meritocratic governance model based on consensus, where anyone interested in the project can join the community to contribute to its development and participate in the decision-making process. This document describes the responsibilities of the participants in the PlatON project, how to participate, the decision-making process, and how to make accomplishments within the community.
Role and Responsibility
User
Users are those community members who have a need for the project. They are the most important members of the community and anyone can become a user with no special requirements.
We hope users participate as much as possible in the project and the community, providing suggestions and needs for the continuous improvement of the project. 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)
-
Active participation in project discussions, giving feedback and feature suggestions
-
Informing developers of the advantages and disadvantages of the project from the perspective of new users
-
Providing moral encouragement and support (a simple “thank you” would make a difference)
Contributor
Contributors are community members who contribute in concrete ways to the project. Anyone can be a contributor. There is no expectation of commitment to the project, no specific skill requirements, and no selection process. Contributors can make contributions in many ways, see How to Contribute to Open Source for more detail.
In addition to their actions as users, contributors may also find themselves doing one or more of the following work:
-
Supporting the community (e.g., answering questions of new users)
-
Reporting bugs (submit issues on GitHub)
-
Fixing bugs
-
Reviewing codes submitted by others
-
Identifying requirements
-
Providing graphics and web design
-
Programming
-
Assisting with project infrastructure (e.g., improving tools and testing)
-
Writing documentation (e.g., tutorials, solutions, technical articles, and improving project documentation)
-
Adding features
-
Translating contents and sorting out information
-
Organizing events (e.g., seminars, online and onsite sharing, etc.)
Contributors engage with the project through the issue tracker and mailing list, 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).
The developer mailing list is the most appropriate place to ask for help when making that first contribution.
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.
Committer (Maintainer)
Committer is a community member of the project development management, and is granted the write access to PlatON-related projects. Committership allows contributors to more easily carry on with their project-related activities, such as making changes to project content directly, instead of submitting changes via patches.
However, this does not mean that committers are free to do what they want. Committers’ changes are still subjected to community review before being officially released. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.
Anyone can become a committer; there are no special requirements, other than 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, its objectives, and its strategy.
The committers of each project are elected individually. 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 takes place on the project’s private management list (pmc). This is 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 on the public mailing list (dev). 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 in nature.
Nominees may decline their appointment as a committer. However, this is not recommended, as the project does not expect any specific time or resource commitment from its committers. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them to the project in any formal way.
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.
Project Management Committee (PMC)
The project management committee consists of those individuals identified as “project owners” on the development site, i.e., the committers and core contributors of the projects and sub-projects. The PMC has additional responsibilities over those of a committer, which generally include reviewing code contributions, participating in strategic planning, approving changes to the governance model, and others. These responsibilities ensure the smooth running of the project.
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 mailing list (pmc) and its archives. This list (pmc) is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public.
The Project Management Committee meets bi-weekly online, and you can suggest issues for discussion in the Project Management Committee Meetings repository.
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 subjected to consensus approval of the current PMC members.
Main responsibilities of the PMC are:
-
Keeping oversight of the commit log messages and ensuring that the codebase does not have copyright and license issues, thus, the project is heading in the desired direction.
-
Keeping oversight of the mailing lists and community to ensure that the open development ideals are upheld.
-
Resolving disputes regarding products of the project.
-
Deciding on the product launch of the project. All releases must be approved by the PMC.
-
Guiding the direction of the project.
-
Striving for and help to facilitate a harmonious productive community.
-
Nominating new PMC members and committers.
-
Maintaining shared resources for the project, including the code base, mailing list, and website.
-
Speaking on behalf of the project.
-
Maintaining governance and other guidelines of the project.
A PMC member is considered “emeritus” by their own declaration. Please send a note to the PMC private mail list and we will follow up to adjust the roster. An emeritus member may also request reinstatement to the PMC. Such reinstatement is subjected to consensus approval of the PMC members. Membership of the PMC can be revoked by the unanimous consensus of PMC members (other than the member in question).
As for the election of committers and PMC members, when we see new people who are committed and consistent, we will discuss each case and conduct the vote on the private PMC mailing list to enable a frank discussion and so that we do not conduct public discussions about people.
PMC Chair
The PMC Chair is 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 main responsibilities include:
-
Ensuring that all governance processes are adhered to.
-
Having the casting vote when the project fails to reach consensus.
-
Submitting quarterly reports to the LatticeX Foundation on the operations of the open source community (including the status of the open source community, and technical advances).
Community Support
All participants in the community are encouraged to provide support for new users. This support is provided 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.
Current channels provided for support are
-
Public mailing list (dev), seek support by sending emails (recommended)
-
GitHub, seek support on the corresponding project’s issue (recommended)
-
LatticeX forum, seek support by posting under the corresponding section of the project
-
Discord, seek support by posting messages on the corresponding channels
Decision Making Process
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 takes place on the project contributors’ mailing list, and relevant records will be publicly offered to encourage openness and stimulate broader community participation.
Occasionally, sensitive discussion occurs on a private list. Private mailing lists are typically used only for personal matters (such as voting on new committers) and for legal matters that require confidentiality. You may not publicly disclose information from such lists without explicit permission to avoid a leak of sensitive information that could cause unnecessary confusion and unwise discussion.
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.
Lazy Consensus
Decision making typically involves the following steps:
-
Proposal
-
Discussion
-
Vote (if consensus is not reached through discussion)
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should submit ideas on the project’s corresponding GitHub issue tracker, or submit a patch implementing the idea via the version-control system (pull request), and send emails to the project’s public mailing list (dev). This will prompt a review and discussion of the idea. The goal of this review and discussion is to gain approval for the contribution.
Generally, as long as there are no explicit objections against the proposal, it is considered to have the support of the community. This is known as lazy consensus - that is, those who have not explicitly expressed an opinion have implicitly agreed to the implementation of the proposal.
For lazy consensus to be effective, it is necessary to allow at least 72 hours (3 days) 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.
Voting
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.
PMC members (including project committers) have official binding votes. However, every member of the community is encouraged to express their opinions in all discussions and all votes.
Certain actions and decisions regarding the project are made by votes on the project development mailing list. Where necessary (e.g. discussion and vote about specific people to be new committers) PMC voting may take place on the private PMC mailing list.
Votes are clearly indicated by the subjected line starting with [VOTE]. Discussion and proposal should have happened prior to the vote. Voting is carried out by replying to the vote mail. Votes are expressed using one of the following symbols:
| +1 | “Yes,” “Agree,” or “the action should be performed”. In general, this vote also indicates a willingness on the behalf of the voter to assist with “making it happen”. |
|---|---|
| +0 | This vote indicates a willingness for the action under consideration to go ahead. The voter, however, will not be able to help. |
| -0 | This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action from going ahead. |
| -1 | This vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action. |
| Abstain | People can abstain from voting. They can either remain silent or express their reason. |
All participants in the project are encouraged to show their preference for a particular action by voting. When the votes are tallied, only the votes of PMC members are binding. Non-binding votes are still useful to enable everyone to understand the perception of an action by the wider community.
Voting can also be applied to changes made to the project codebase. These typically take the form of a veto (-1) in reply to whether the submitted patches are approved.
Types of Approval
Different actions require different types of approval:
| Type | Description |
|---|---|
| Consensus approval | Consensus approval requires three binding +1 votes and no binding votes. |
| Lazy consensus (Majority consensus) | A lazy majority vote requires three binding +1 votes, and more binding +1 votes than binding -1 votes. |
| Lazy approval | An action with lazy consensus is implicitly allowed unless a binding -1 vote is received. Depending on the type of action, lazy majority or consensus approval must be obtained. |
| 2/3 majority | Some strategic actions require a 2/3 majority of PMC members; Such actions typically affect the foundation of the project. The higher requirement is to ensure that this change is strongly supported. To vote through, 2/3 of the votes cast must be +1. |
| Unanimous consensus | All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1). |
Vetoes
A valid veto cannot be over-ruled, it can only be withdrawn by its issuer. Any veto must be accompanied by reasoning and be prepared to defend it.
The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid. In case of disputes about whether a veto is valid, then the opinion of the PMC chair is final.
If you disagree with a valid veto, then you must engage the person casting the veto to further discuss the issues. The vetoer is obliged to vote early and then to work with the community to resolve the matter.
If a veto is not withdrawn, the action that has been vetoed must be reversed in a timely manner.
Actions
This section describes the various actions which are undertaken within the project, the corresponding approval required for that action, and those who have binding votes over the action.
| Actions | Description | Approval | Binding Votes |
|---|---|---|---|
| Code change | A change made to a codebase of the project by a committer. This includes source code, documentation, website content, etc. | Lazy approval | PMC members |
| Release plan | Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority). | Lazy majority | PMC members |
| Product release | When a release of one of the project’s products is ready, a vote is required to accept the release as an official release of the project. | Lazy majority | PMC members |
| Adoption of new codebase | When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project. | 2/3 majority | PMC members |
| New committer | When a new committer is proposed for the project. | Consensus approval | PMC members |
| New PMC member | When a new member is proposed for the PMC. | Consensus approval | PMC members |
| Reinstate emeritus member | An emeritus PMC member can be reinstated. | Consensus approval | PMC members (excluding the member in question) |
| Committer removal | When removal of commit privileges is sought. | Unanimous consensus | PMC members (excluding the committer in question if a member of the PMC) |
| PMC member removal | When removal of a PMC member is sought. | Unanimous consensus | PMC members (excluding the member in question) |
Voting timeframes
Votes are normally open for a period of one week to allow all active voters time to consider the vote. If the vote has not achieved a quorum (the chair decides if sufficient people have voted), then it can be extended for another week. If still no quorum, then the vote fails, it would need to be raised again later. Votes relating to code changes are not subjected to a strict timetable, but should be made as timely as possible.
Be careful about holidays when calling a vote. This is hard when we do not know customs in every part of the world. So if someone knows that there is a problem with the vote timing, then please say so.
Ultimatum and breakdown
For breakdown situations and those requiring unanimous consensus, if this consensus cannot be reached within the extended timeframe, then the LatticeX Foundation and the PMC Chair will make the ultimate decision in line with the project’s strategic objectives and direction.
Communication channels
The primary mechanism for communication is the mailing lists (dev). Anyone can participate, no matter what their time zone.
All decisions are made on the “dev” mailing list. The main channel for user support is the “user” mailing list.
Occasionally we will use other communication channels such as Discord. These are used only for a specific purpose and are not permanently available.
Lastly, private discussions are discouraged.
Contribution and acknowledgment
In an Open Source Project, anyone can find ways to participate and contribute, such as design discussion, oversight, testing, documentation, bug fixes, and much more.
The principles of open development are to ensure that everyone is recognized and feels a productive part of the community.
Because of the diversity of contributions, we use the following method to provide recognition:
-
All developers are encouraged to participate on the mailing lists, treat each other with respect, and openly collaborate.
-
Contributors are encouraged to report bugs and add patches via the issue, to enable clear tracking of the contributors
-
Committers should respond timely to the patch merge requests of contributors
-
Committers should add an entry for each significant contribution to the project’s changes document, linking to the relevant issue and showing the contributor’s name.
-
The existing PMC would invite new contributors to become new committers/PMC members.
-
Committers/PMC members are listed
As discussed above, there is no specific documentation which lists each contributor and their work. For those who are interested, there are various mechanisms for confirmation: Use general internet search services; search the mailing list using committer IDs and using contributor names; browse the changes page, etc.