From c4a4f518bbd53a377c359f3514b088fa4e415471 Mon Sep 17 00:00:00 2001 From: Roman Yurchak Date: Wed, 3 Mar 2021 19:09:05 +0100 Subject: [PATCH] RFC pyodide governance and decision-making process (#1229) Co-authored-by: Hood Chatham --- docs/development/contributing.md | 2 + docs/index.rst | 1 + docs/project/governance.md | 95 ++++++++++++++++++++++++++++++++ 3 files changed, 98 insertions(+) create mode 100644 docs/project/governance.md diff --git a/docs/development/contributing.md b/docs/development/contributing.md index 336bc43aa..43dcbfc76 100644 --- a/docs/development/contributing.md +++ b/docs/development/contributing.md @@ -1,3 +1,5 @@ +(how_to_contribute)= + # How to Contribute Thank you for your interest in contributing to PYODIDE! There are many ways to contribute, and we appreciate all of them. Here are some guidelines & pointers for diving into it. diff --git a/docs/index.rst b/docs/index.rst index e0ef436fc..71aa2eb40 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -64,6 +64,7 @@ information about the project's organization. project/about.md project/code-of-conduct.md + project/governance.md project/changelog.md project/related-projects.md diff --git a/docs/project/governance.md b/docs/project/governance.md new file mode 100644 index 000000000..c6d8c33f8 --- /dev/null +++ b/docs/project/governance.md @@ -0,0 +1,95 @@ +# pyodide governance and decision-making + +The purpose of this document is to formalize the governance process used by the +pyodide project, to clarify how decisions are made and how the various +members of our community interact. +This document establishes a decision-making structure that takes into account +feedback from all members of the community and strives to find consensus, while +avoiding any deadlocks. + +Anyone with an interest in the project can join the community, contribute to +the project design and participate in the decision making process. This +document describes how to participate and earn merit in the pyodide community. + +## Roles And Responsibilities + +### Contributors + +Contributors are community members who contribute in concrete ways to the +project. Anyone can become a contributor, and contributions can take many +forms, for instance, answering user questions – not only code – as detailed in +the {ref}`how_to_contibute` + +### Community members team + +The community members team is composed of community members who have permission on +Github to label and close issues. Their work is +crucial to improve the communication in the project. + +After participating in pyodide development with pull requests and reviews for a +period of time, any contributor may become a member of the team. +The process for adding team members is modeled on the [CPython project]( +https://devguide.python.org/triaging/#becoming-a-member-of-the-python-triage-team). +Any core developer is welcome to propose a pyodide contributor to join the +community members team. Other core developers are then consulted: while it is expected +that most acceptances will be unanimous, a two-thirds majority is enough. + +### Core developers + +Core developers are community members who have shown that they are dedicated to +the continued development of the project through ongoing engagement with the +community. They have shown they can be trusted to maintain pyodide with +care. Being a core developer allows contributors to more easily carry on +with their project related activities by giving them direct access to the +project’s repository and is represented as being a member of the core team on the +pyodide [GitHub organization](https://github.com/orgs/pyodide/teams/core/members). +Core developers are expected to review code +contributions, can merge approved pull requests, can cast votes for and against +merging a pull-request, and can make decisions about major changes to the +API (all contributors are welcome to participate in the discussion). + +New core developers can be nominated by any existing core developers. Once they +have been nominated, there will be a vote by the current core developers. +Voting on new core developers is one of the few activities that takes place on +the project's private communication channels. While it is expected that most votes +will be unanimous, a two-thirds majority of the cast votes is enough. The vote +needs to be open for at least one week. + +Core developers that have not contributed to the project (commits or GitHub +comments) in the past two years will be asked if they want to become emeritus +core developers and recant their commit and voting rights until they become +active again. + + +## Decision Making Process + +Decisions about the future of the project are made through discussion with all +members of the community. All non-sensitive project management discussion takes +place on the project contributors' [issue +tracker](https://github.com/pyodide/pyodide/issues) and on [Github +discussion](https://github.com/pyodide/pyodide/discussions). +Occasionally, sensitive discussion occurs on a private communication channels. + +pyodide uses a "consensus seeking" process for making decisions. The group +tries to find a resolution that has no open objections among core developers. +At any point during the discussion, any core-developer can call for a vote, +which will conclude two weeks from the call for the vote. This is what we +hereafter may refer to as “the decision making process”. + +Decisions (in addition to adding core developers as above) +are made according to the following rules: + +* **Maintenance changes**, include for instance improving the wording in the + documentation, updating CI or dependencies. Core developers are expected to + give “reasonable time” to others to give their opinion on the Pull Request in + case they’re not confident that others would agree. If no further review on + the Pull Request is received within this time, it can be merged. If a review + is received, then the consensus rules from the following section apply. + +* **Code changes in general, and especially those impacting user facing APIs**, + as well as more significant documentation changes, require review and + approval by a core developer and no objections raised by any core developer + (lazy consensus). This process happens on the pull-request page. + +* **Changes to the governance model** use the same decision process outlined + above.