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

GOVERNANCE.md

@@ -0,0 +1,130 @@
+# 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
+
+There are two broadly defined roles in the Jujutsu project: **Maintainers** and
+**Contributors**.
+
+### Maintainers
+
+At the top of the hierarchy are the **Maintainers**. We consider maintainers to
+be the people who contribute, review, guide, and collectively make decisions
+about the direction and scope of the project.
+
+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.
+- When necessary, participate in a collective voting process to resolve
+conflicts and make decisions for which there is no clear answer.
+
+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:
+
+- Yuya Nishihara
+- Martin von Zweigbergk
+- Waleed Khan
+- Ilya Grigoriev
+- Austin Seipp
+
+### 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
+- Submit patches or 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
+
+While these are all generally quite valuable, they don't directly contribute to
+the existing community of users where they are at, and on their own do not
+constitute "active participation".
+
+Contributors and their input are valued and their input is expected to be taken
+and respected by Maintainers; not every discussion will result in a change, but
+it is intended that every voice will be heard.
+
+## 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
+
+A final decision requires more than half of the participating votes (i.e.
+excluding abstaining votes.)
+
+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 (including the vote of the
+Maintainer in question.) This can be due to lack of participation, conduct
+violations, et cetera. Note that Maintainers are subject to a higher set of
+behavioral and communicative standards than average contributor or participant.