mirror of https://github.com/pyodide/pyodide.git
97 lines
4.9 KiB
Markdown
97 lines
4.9 KiB
Markdown
(project-governance)=
|
||
# 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 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
|
||
{any}`how_to_contribute`.
|
||
|
||
### 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.
|