Taro Contributor Promotion System
In order to establish a more complete and sustainable Taro open source ecosystem and highlight the value of contributors, we have formulated the "Taro Contributor Promotion System" with reference to the mature open source community operating mechanism to provide developers and contributors who love and like Taro technology with more clarity. participation mechanism and honor incentive mechanism.
promotion role
As shown in the figure, there are 4 promotion roles: individual contributor & ecological individual contributor, assistant, collaborator & ecological collaborator, technical committee member. The promotion mechanism makes consensus decisions through nomination + voting. The promotion path is as follows:
- Individual Contributor → Assistant → Collaborator → Technical Committee Member
- Individual Contributor → Collaborator → Technical Committee Member
- Ecological Individual Contributor → Ecological Collaborator → Technical Committee Member
Those who are inactive within one year will be automatically downgraded, and those who have made outstanding contributions can apply for retirement.
Individual Contributor & Ecological Individual Contributor (Individual Committer)
Any individual developer who agrees to the "Taro Code of Conduct" can submit a pull request based on the "Contributor Guidelines" , bug feedback & fixes, new feature proposals or PRs, and will be listed as individual contributors in Taro's official documentation . Contributors can be nominated as collaborators when their valuable work is noticed by other collaborators.
Any tools, plugins, training, tutorials, etc. based on or around the Taro ecosystem will be listed as individual contributors to the ecosystem in the official Taro documentation .
Assistant (Triage)
Responsible for the maintenance of new issues in the NervJS/taro and NervJS/taro-ui warehouses, tagging issues or pull requests, commenting, closing and reopening issues or pull requests, and assigning bugs or features to specific working groups.
- The purpose is to reduce the issue list, keep the issue tracked in time, and promote newcomers to participate and contribute pull requests.
- Equity Github NervJS group Member permission, related project Triage permission, can manage issues and pull requests (no write permission).
- Application method Anyone who has a comprehensive understanding of the Taro project and has in-depth development experience can submit a pull request in NervJS/taro README.md , explaining the motivation for applying to become an assistant and agreeing to the code of conduct for this project, with the consent of 2 collaborators to pass. The reference template for applying for a pull request is as follows:
- The exit mechanism periodically removes assistants that have been inactive for 6 months.
Collaborator & Eco-Collaborator
Responsible for maintaining the NervJS/taro and NervJS/taro-ui repositories, helping users and junior contributors, participating in specific working groups to contribute code and documentation to the current project, reviewing and commenting on issues and pull requests.
- The goal is to continuously enrich Taro features, performance, security, and more.
- Equity Github NervJS group Member permission, Github Write permission, can submit commits to NervJS/taro repository, can configure continuous integration tasks, be responsible for pull request review and merge, 1 PR merge requires at least 2 collaborators or 1 technical committee member to agree You can enter the observation period, and you can officially become a collaborator after the observation period of 3 months.
- The application method collaborators nominate individual contributors with outstanding contributions, and decide whether they can become collaborators through a voting mechanism. A qualified collaborator should have: advanced technology and excellent business skills; barrier-free communication, at least reading and writing; good character, able to study, not easily give up halfway; humble attitude, able to accept the opinions of others; Owner mentality, proactive. The reference template for applying for a pull request is as follows:
- Exit Mechanism For inactive collaborators, the Technical Committee has the right to remove them or set them to emeritus status, and emeritus members can reapply to the Technical Committee for active status. If a collaborator does not make any contribution for more than 6 months, it will be automatically set to emeritus status.
Technical Steering Committee
Responsible for technical direction, project management, project release, contribution policy, warehouse hosting, code of conduct, maintaining a list of collaborators, and regularly participate in TSC activities.
- The purpose is to solve technical problems and new directions that are difficult to reach consensus.
- Stakes Github NervJS group Owner permissions.
- Application Method New TSC members need to be nominated by other TSC members and discussed and voted. The reference template for applying for a pull request is as follows:
- Exit Mechanism Within a quarter, if you are absent from 75% of the activities and do not participate in any voting, you will be automatically removed from the list. Members may apply for a temporary "retirement".
Operating mechanism
As shown in the figure, the operating mechanism includes the technical committee and five subordinate teams (Core Team, Plugins Team, Platform Team, Innovation Team , and Community Team). The technical committee is composed of technical committee members, responsible for technical direction, project management, contribution policy, warehouse hosting, code of conduct, maintenance of the list of collaborators, etc. The chairman of the technical committee is responsible for regularly organizing meetings. The working group is composed of collaborating members, and each direction has an Owner who is responsible for the development progress of the relevant working group.
team
- Core Team
- The Cli working group is primarily responsible for the development and maintenance of the Taro command line tool.
- The Compile working group is responsible for maintaining and optimizing the applet and the H5 compilation system.
- The Runtime working group is responsible for maintaining the applet runtime system.
- The Plugin team is responsible for maintaining various Taro plugins, including side platform plugins, React, Vue DevTools, etc.
- The terminal platform plug-in working group is responsible for maintaining various terminal platform plug-ins, including the adaptation of WeChat, Alipay, Baidu, ByteDance, QQ, JD, Enterprise WeChat, Feishu, Kuaishou, DingTalk, Xiaohongshu and other manufacturers' small programs, etc. .
- The hybrid development team is responsible for maintaining the mutual call function between Taro and native applets, and developing native plug-ins for Taro.
- The Platform team is responsible for cross-platform development such as App, Web, and Open Harmony.
- The H5 working group is responsible for maintaining various modules of H5, including routing, component library, API library, etc.
- The React Native working group is responsible for the development of the React Native adaptation core, component library, and API library.
- The Open Harmony working group is responsible for the development of the Harmony adaptation core, component library, API library and other parts.
- Fast Application Working Group
- The innovation team Taro is innovating and exploring new directions, such as wasm, rust, vite, flutter, electron, etc.
- UI framework interest group TaroUI, NutUI and other UI libraries and the development and management of other types of ecological tools.
- The community team is responsible for the Taro ecosystem and operation, as well as the operation and promotion of the Taro community.
Technical committee biweekly meeting
- Time: Before Thursday every fortnight, announce the content and date of the next meeting in the TSC issue.
- Issue: Issues from items tagged tsc-agenda under Taro. Submit the meeting minutes pull request after the meeting. The non-committee can be invited to participate in each meeting, but there is no right to vote.
Voting mechanism based on consensus decision
In each promotion voting session, based on the principle of consensus decision-making, a majority consensus is reached in principle.
- Issues to be voted on need to be known to members before the meeting, giving members enough time to research and think
- When an issue is about to reach an agreement, it is necessary to ask "Is there any objection?" before closing the question, so as to know the last chance of objection
- When an issue cannot be reached, a majority of votes can be made to support whether to postpone it to the next meeting, otherwise the discussion must continue
- Issues can be passed after meeting the "majority victory", and members can abstain from voting
Guidance/training mechanism
Assistants, collaborators and technical committee members provide corresponding guidance and training at each stage, so that new promotions can quickly start work.
Role members click below to see more: