Developer Community Governance Implementation Rules (First Draft)
Our goal is to make PlatON/Alaya an open-source project that is community-driven, open development, and sustainable.
PlatON/Alaya are open-source projects, and all codes are released on the GitHub community. The projects will be governed by a meritocratic governance model based on consensus, where anyone interested in the project can join the community, contribute to its development and participate in the decision-making process. This document describes the responsibilities of the participants in the PlatON/Alaya project, how to participate, and the rules of procedure.
Basic Principles
Open and inclusive, public and transparent, respect and recognition
How to contribute to PlatON/Alaya open source
As an open-source project, the code, documentation, and products that make up an open-source project are created, tested, used, discussed, and improved by community members of the project. These processes can be broken down into a myriad of tasks that require different skills, levels of involvement, and technical expertise. Therefore, anyone can contribute to an open-source project.
Click on the following link to learn more about how to contribute to open-source projects and why you should get involved:
-
How to contribute to open-source 如何为开源做贡献 | Open Source Guides
-
Roles in open source Roles in open source projects
All of these contributions help keep the project active and strengthen the community. Therefore, we encourage the participation of a broader community of developers and project teams.
Organizational Structure
Roles and Responsibilities
Contributor
All active GitHub users involved in the project are contributors, and contributors have the opportunity to be nominated as new maintainers by existing ones (see note below).
As the project developer community is still in its start-up phase, the currently preferred types of contributors are mainly developers who are willing to participate in project development, technical support, and translation.
| Types of Contributors | Main Responsibilities |
|---|---|
| Core Developer | Mainly responsible for the development and support of PlatON/Alaya’s underlayer, tools, and application 1. Community Support: Answer questions for new users, analyze and respond to key problems from Issue (as well as LatticeX forum & Discord) 2. Test and report bugs: Code review, test and submit issues to Issue for existing versions and PR 3. Fix bugs: analyze and fix bugs reported in Issue 4. Submit proposals 5.Participate in the design and development of new features: optimize and improve existing protocol modules and logic 6.Prepare and update project documentation: - Frequently Asked Questions - Write and summarize FAQs for the project - Project Guide and Tutorials - Write and optimize Readme for the project; contribute to guides, FAQs, and solutions (documentation, videos), etc. - User Guide - Write and maintain a comprehensive user guide for your project - Developer Guide - Write, improve and update the developer’s guide for the project 7. Disseminate and promote the project to take in more community contributors 8. Research on core technology topics |
| Translator | Responsible for the translation of all technical documentation and products of the project 1. Translate contents from GitHub Issue, PIP, PR, and ReleaseNote 2. Translate documentation of the project |
If you wish to contribute to the above contents, please contact the core developers on Our Discord channel to ensure that your contribution is in line with the overall project concept and to get early feedback and suggestions that can make your job easier.
Maintainer
Maintainers are community members who have administrative access to the GitHub open-source repository, including project PMs and committers, and are mainly responsible for the maintenance and management of the GitHub, keeping the GitHub active, and ensuring that the projects are going in the right direction.
| Types of Maintainers | Main Responsibilities |
|---|---|
| Committer | Mainly responsible for PR management and facilitating the resolution of Issues: Issue: Respond to issues and discuss the solution PR: PR classification, tagging, code review, promote PR improvement, merge code (logs need to be linked with corresponding Issue, PIP and identify contributors), publish release, close PR. |
| PM | Mainly responsible for managing project task and coordinating core developers 1. Assign and follow up core developer tasks 2. Responsible for maintaining the repository code branches, following up the status of issues, PIPs, and PRs, updating the project progress, following up the PR review progress: Issue: Issue classification, tagging, facilitating Issue resolution, closing Issue PIP: PIP content and format review, facilitate PIP discussions, facilitate PIP implementation 3. Maintain the contributor’s list of each project (GitHub ID and contact email) |
New maintainers need to be invited by existing maintainers and approved to join by a vote of the PMC (Project Management Committee). Each project can be assigned with more than one maintainer.
Project Management Committee (PMC)
The Project Management Committee (PMC) is initially composed of all maintainers, and future members need to be invited by existing PMC members. Nominees can become official members after being approved by the discussion and vote of the existing PMC members. (including Alaya PMC, PlatON PMC)
PMC members own the right to vote on new maintainers and PMC members. They also have the final vote when the community cannot reach a consensus. [The community uses lazy consensus, meaning that decisions are agreed to by default if no explicit objections were raised by community contributors and maintainers within 72 hours of release.]
The Main responsibilities of the PMC are:
-
Review the GitHub commit log to ensure that the projects are moving in the expected direction.
-
Final decision making on actions that do not reach consensuses in the community
-
Decide on the product launch of the project
-
Nominate new PMC members and maintainers.
-
Organize core developer meetings
-
Maintain shared resources for the project, including the code base, mailing list, and website.
The Project Management Committee has a Chairman who is elected by the PMC for a three-month term and is eligible for re-election. The PMC Chairman acts as the organizer, coordinator, and facilitator to ensure that all management procedures of the PMC are followed.
The Main responsibilities include:
-
Collect and organize community contributions and apply for funding from the LatticeX Foundation
-
Submit 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)
-
Organize community developer meetings, including gathering meeting issues
-
Initiate voting for new PMC members and maintainers, and tally the results and publish (new members can join if more than 2/3 voted yes)
-
Initiate decision voting, and tally the results and publish (more than 2/3 voted yes means pass)
Participation Methods
Contribution Methods
- Active contribution
As an open-source community, anyone can get rewards from contributing to an open-source project, regardless of the size of the contribution.
- Task assignment
Tasks are assigned directly by the committers to potential contributors and maintainers to claim. Contributors or maintainers can be full-time or part-time and are assigned different tasks depending on their time and ability.
Appraisal and Funding
The PMC Chairman collects and collates the performance of contributors and maintainers and reports it back to the LatticeX Foundation to apply for incentives.
The LatticeX Foundation adopts a funding model which allocates more funding to good contributions, while reduces or stops funding to poor contributions.
Means of Communication
The main channel for communication is the projects’ GitHub (PlatON GitHub: PlatON · GitHub Alaya GitHub: AlayaNetwork · GitHub), or through posts in LatticeX Forum.
When necessary, communication via phone or web conference, Discordopen channels, open mailing lists, are also welcome.
Rules of Procedure
Any member can propose ideas and improvements to the project for the community to discuss (submit Issue or PR). All improvement suggestions within the community are collected and analyzed by the core community developers and submitted to the community (GitHub, forums, developer meetings) for full discussion to form a formal proposal, and any community member can approve or disapprove of an improvement proposal in the proposal repository, but you must provide a reason for disapproving.
Generally, as long as there are no explicit objections against the proposal, it is considered to win the support of the community, and the process normally takes 72 hours (3 days). 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.
If explicit objections are raised against a proposal, we will further discuss and vote via a developer meeting, or a public mailing list. PMC members have binding votes, and the proposal will pass if over 2/3 of the members agree. All process records will be openly and transparently released to the public.
Core Developer Meeting
A core developer meeting is initiated by core developers and convenes once every 1-2 weeks on average, attendees include:
-
Core developers
-
Maintainers (including PMs and committers)
-
Other contributors interested in participating (including contributors currently active in Issues/PR/PIP, translators, etc.)
Meeting issues include, but were not limited to:
-
Discuss the analysis and processing progress of currently active Issues
-
Discuss optimization suggestions submitted by developers on GitHub or the forums
-
Review of PR or PIP
-
Sharing of the findings of surveys or researches by core developers or contributors
The meeting issues will be posted in meeting-issues. We recommend host the meeting online, and the meeting initiator should designate a host and a minutes taker for each meeting. The minutes and recordings of meetings should both be archived in the meeting repository, and upload the recording of the meetings to YouTube and Bilibili.
Community Developer Meeting
The PMC holds a community developer meeting once every 1-3 months according to the iteration plan, and the regular issues of the meeting include:
-
The regular issues of the meeting include:
-
Keep community developers posted about the current work progress of the Foundation and PMC
-
Gather feedback from community developers
-
Voting on key releases and features
-
Q&A on key issues such as network iterations and feature upgrades
Anyone with an interest in PlatON/Alaya can attend, and the form of the meeting will be the same as the Core Developer Meeting.