pyodide/docs/project/governance.md

(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.