From 02500e52487cc15bf868c0e8f2e0864b49e927ce Mon Sep 17 00:00:00 2001 From: Austin Seipp Date: Fri, 6 Dec 2024 13:32:43 -0600 Subject: [PATCH] meta: add initial `GOVERNANCE.md` This is the result of a lot of back and forth, the weekly efforts of the governance working group, consisting of: - Martin von Zweigbergk (martinvonz) - Waleed Khan (arxanas) - Emily Shaffer (nasamuffin) - Austin Seipp (thoughtpolice; yours truly) Many thanks as well to emeritus member Khionu Sybiern, who helped kickstart this whole process. Signed-off-by: Austin Seipp --- GOVERNANCE.md | 144 ++++++++++++++++++++++++++++++++++ docs/governance/GOVERNANCE.md | 1 + mkdocs.yml | 1 + 3 files changed, 146 insertions(+) create mode 100644 GOVERNANCE.md create mode 120000 docs/governance/GOVERNANCE.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 000000000..67e635cf2 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,144 @@ +# Jujutsu Governance + +## Overview + +Jujutsu is an open source project, led, maintained and designed for a worldwide +community. Anyone who is interested can join, contribute, and participate in the +decision-making process. This document is intended to help you understand how +you can do that. + +## Project roles + +We greatly appreciate everyone's contributions, and Jujutsu has benefited +greatly from people who shared a single idea, change, or a suggestion, without +ever becoming a regular contributor. We also want everybody to feel welcome to +share their suggestions for the project (as long as you follow the Community +Guidelines). + +There are two special roles for participants in the Jujutsu projects: +Maintainers and Contributors. + +The role of the Maintainer is formally defined. These are the people empowered +to collectively make final decisions about most aspects of the project. They are +expected to take community's input seriously and to aim for the benefit of the +entire community. + +The role of a Contributor is less formal. In situations where opinions become +numerous or contentious, it is acceptable for the maintainers to assign more +weight to the voices of the more established Contributors. + +### Maintainers + +**Maintainers** are the people who contribute, review, guide, and collectively +make decisions about the direction and scope of the project (see: +[Decision Making](#decision-making)). Maintainers are elected by a +[voting process](#adding-and-removing-maintainers). + +A typical Maintainer is not only someone who has made "large" contributions, but +someone who has shown they are continuously committed to the project and its +community. Some expected responsibilities of maintainers include (but are not +exclusively limited to): + +- Displaying a high level of commitment to the project and its community, and + being a role model for others. +- Writing patches — a lot of patches, especially "glue code" or "grunt + work" or general "housekeeping"; fixing bugs, ensuring documentation is always + high quality, consistent UX design, improving processes, making judgments on + dependencies, handling security vulnerabilities, and so on and so forth. +- Reviewing code submitted by others — with an eye to maintainability, + performance, code quality, and "style" (fitting in with the project). +- Participating in design discussions, especially with regards to architecture + or long-term vision. +- Ensuring the community remains a warm and welcoming place, to new and veteran + members alike. + +This is not an exhaustive list, nor is it intended that every Maintainer does +each and every one of these individual tasks to equal amounts. Rather this is +only a guideline for what Maintainers are expected to conceptually do. + +In short, Maintainers are the outwardly visible stewards of the project. + +#### Current list of Maintainers + +The current list of Maintainers: + +- Austin Seipp (@thoughtpolice) +- Ilya Grigoriev (@ilyagr) +- Martin von Zweigbergk (@martinvonz) +- Waleed Khan (@arxanas) +- Yuya Nishihara (@yuja) + +### Contributors + +We consider contributors to be active participants in the project and community +who are _not_ maintainers. These are people who might: + +- Help users by answering questions +- Participating in lively and respectful discussions across various channels +- Submit high-quality bug reports, reproduce reported bugs, and verifying fixes +- Submit patches or pull requests +- Provide reviews and input on others' pull requests +- Help with testing and quality assurance +- Submit feedback about planned features, use cases, or bugs + +We essentially define them as **people who actively participate in the +project**. Examples of things that would _not_ make you a contributor are: + +- Submitting a single bug report and never returning +- Writing blog posts or other evangelism +- Using the software in production +- Forking the project and maintaining your own version +- Writing a third-party tool or add-on + +While these are all generally quite valuable, we don't consider these ongoing +contributions to the codebase or project itself, and on their own do not +constitute "active participation". + +## Processes + +For the purposes of making decisions across the project, the following processes +are defined. + +### Decision-Making + +The person proposing a decision to be made (i.e. technical, project direction, +etc.) can offer a proposal, along with a 2-to-4 week deadline for discussion. +During this time, Maintainers may participate with a vote of: + +A) Support B) Reject C) Abstain + +Each Maintainer gets one vote. The total number of "participating votes" is the +number of Maintainer votes which are not Abstain. The proposal is accepted when +more than half of the participating votes are Support. + +In the event that a decision is reached before the proposed timeline, said +proposal can move on and be accepted immediately. In the event no consensus is +reached, a proposal may be re-submitted later on. + +This document itself is subject to the Decision-Making process by the existing +set of Maintainers. + +### Adding and Removing Maintainers + +An active Contributor may, at any given time, nominate themselves or another +Contributor to become a Maintainer. This process is purely optional and no +Contributor is expected to do so; however, self-nomination is encouraged for +active participants. A vote and discussion by the existing Maintainers will be +used to decide the outcome. + +Note that Contributors should demonstrate a high standard of continuous +participation to become a Maintainer; the upper limit on the number of +Maintainers is practically bounded, and so rejection should be considered as a +real possibility. As the scope of the project changes, this limit may increase, +but it is fundamentally fluid. (If you are unsure, you are free to privately ask +existing Maintainers before self-nominating if there is room.) + +A Maintainer may, at any time, cede their responsibility and step down without a +vote. + +A Maintainer can be removed by other Maintainers, subject to a vote of at-least +a 2/3rds majority from the existing Maintainer group (excluding the vote of the +Maintainer in question). This can be due to lack of participation or conduct +violations, among other things. Note that Maintainers are subject to a higher +set of behavioral and communicative standards than average contributor or +participant. diff --git a/docs/governance/GOVERNANCE.md b/docs/governance/GOVERNANCE.md new file mode 120000 index 000000000..187da4f7f --- /dev/null +++ b/docs/governance/GOVERNANCE.md @@ -0,0 +1 @@ +../../GOVERNANCE.md \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 7f14f0000..dd566e7d5 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -137,6 +137,7 @@ nav: - 'Design Doc Blueprint': 'design_doc_blueprint.md' - 'Releasing': 'releasing.md' - 'Temporary Voting for Governance': 'governance/temporary-voting.md' + - 'Governance': 'governance/GOVERNANCE.md' - 'Design docs': - 'git-submodules': 'design/git-submodules.md'