SOFAStack & MOSN Community Role Description v2.0
Layotto is a sub-project of the MOSN community. This paper presents proposal v2.0 on the role of the SOFAStack & MOSN community
The proposal would initially be linked to the Layotto and SOFA-Registration project
Design objectives
- Attracting more people into the communityMaintainer, Manager rather than merely maintaining the community by the core developer, single point bottlenecks
- Increase community activity
Principles
Coming a friend
Decrease the threshold so that interested enthusiasts can participate in community maintenance and management
Community Title：All Community titles, Competencies and Irrelevance of Companies/Organizations of Participants
In order to motivate everybody to get the project to get involved in the community for personal hobbies/personal honours, regardless of where the company goes or SOFAStack MC member/Co-founder; to involve every interested technical student in the core decisions of the community and promote community activism.
For example, a developer created Project A which, after many years, continues to be the Co-founder of Project A even if he is no longer involved in community maintenance, runs over several companies, has experienced storm, started off, decided to switch off as a programmer and opened a fire boiler.
For example, a programmer who is the owner and not a programmer, who can also be a PMC member or Project Reviewer, provided he has sufficient contributions to the project.
Definitive return：establishes clear promotion rules for community members
What contribution can members of the community make to promotion?There is a transparent and specific rule that allows community students to grow from Contribor to Committer or Maintainer,Let people feel that they are “investing in a reward” to develop their own promotion rules for each project, but to make clear what can be done so that people see the return to the community
Communitization of decision-making
Communitize：Needs and Technology Program Public Review
Evaluation of critical needs and evaluation of technical programmes should be conducted in an open manner within the community** rather than in internal review sessions for several persons**
For example, when conducting a technical programme review, community members can organize online meetings, live broadcasts and allow each interested person to watch and participate in meetings in their own user communities or in the Core Team group.If you feel too heavy a live broadcast, the issue is proposed as well.
Invert：3 are a fire boiler owner and also a project's Committer.He was very keen to participate in community building, but was not accompanied by any evaluation of the technology programme, which was a dismal one.
Community promotion
Promotion rules, nominations to be decided by community members in a group
Interpretation of new roles
Lifelong Honour (Project Founder)
Role Description
Honour for life, but not for power. For example, a developer created Project A and has been a Co-founder of Project A even after many years, even if he is no longer involved in community maintenance or switching as a programmer.
This is an honour and an incentive to make people feel open for their personal influence
Designing the purpose of this role
Incentives for new open source projects for SOFAStack and MOSN communities (several students have thought in the second half of the year and sofa-bolt-go is already developing);
Inspire the current owner (if it is the founder);
Thanks for the initial developers who have left the community, invite back to the community
Member States
Role Description
Add a new Member’s role to invite to join the organization, and the profile page will show the logo.
Of course, given that in the past some projects were organized only by the Community, with a higher threshold, the role was optional and not mandatory, projects could decide whether or not to join the role in their own project. The idea is to join this role on a trial basis in Layotto and SOFA-Registry.
Purpose to add this role?
After joining the organization, the github profile page of the contributor shows the organization's logo, which is cool enough to motivate people to join the community and contribute.
Member's duties
Member's duties are code reviewed and issues processed and can be Reviewer if the member handles issues and code review with a high frequency (see below);
The github's permissions assigned by the Member
Default permission, no write permission.However, LGTM is active
Conditions for becoming a Member (conditions for joining organizations)
Each project itself
Reviewer
Role Description
Like Member, it is responsible for code review and for dealing with issues as well as recognition and appreciation of Members' contributions.Long-term review contributions can promote Committer
Reviewer has some responsibility for review.For example, a issue/Pull request involves a module in which project maintainers can request reviewers for the module to review and take responsibility for the puzzle.For example, you can request the WASM module reviewer @zhenjunMa if someone makes a bug to the WASM module
Condition to Reviewer
Each project itself
Whether Reviewer will return to Member
Each project customizes.The different views collected at this time are：
After becoming Reviewer, the responsibility is clearer than that of the member; it is to deal with issues and PR; it must remain at least two issues per week or one PR; if there is a two-week processing frequency within a month, it will return to the member;
b. Believing that setting a target for Reviewer is too odd for KPI to work with KPI
Reviewer assigned githuborganization permissions
Purpose to add this role?
-
I would like to get the MOSN and SOFAStack communities to respond faster, and to respond more quickly (in terms of how to improve the response speed on issue), I am not thinking about what to do and welcome suggestions
-
Community decision making,code review can be made by active contributors, don't want only one or two people to review
-
Many enthusiasts may be empty for some time, empty for some time (domestic programmers status quo...) and free time for review of PRs and issues to participate in, contribute to and learn about changes in the project's time frame
When code is reviewed, can one vote LGTM or two votes be merged with LGTM?
A: The current idea is to refer to the vue community, if the review responds to LGTM, but without merge permission, project defenders (writers are) are responsible for the actual mergers. Project defenders who have trust in reviewer can simply look at prs and merge without problems; if the printer changes are big and less assured, they have to look carefully at prs themselves.
Thus, about two votes are combined.
This design is intended to force project core defenders to understand each pr, every change.
Other
Use English as far as possible on issues and PRs
The type of IMs to be used is to be discussed at the discretion of each project. Options include micromessages, Slack, gitter
Community-based meetings themselves
References
Apollo https://github.com/apolloconfig/apollo/pull/3670 https://github.com/apolloconfig/apollo/issues/3684 https://github.com/apolloconfig/apollo/discussions/categories/announcements
Tidb's community-based organization https://pingcap.com/blog-cn/tidb-community-upgrade/