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