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 <[email protected]>

Author: thoughtpolice

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.

docs/governance/GOVERNANCE.md

@@ -0,0 +1 @@
+../../GOVERNANCE.md

mkdocs.yml

@@ -132,6 +132,7 @@ nav:
       - 'Design Docs': 'design_docs.md'
       - 'Design Doc Blueprint': 'design_doc_blueprint.md'
       - 'Temporary Voting for Governance': 'governance/temporary-voting.md'
+      - 'Governance': 'governance/GOVERNANCE.md'
 
 - 'Design docs':
     - 'git-submodules': 'design/git-submodules.md'