|
| 1 | +# Jujutsu Governance |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +Jujutsu is an open source project, led, maintained and designed for a worldwide |
| 6 | +community. Anyone who is interested can join, contribute, and participate in the |
| 7 | +decision-making process. This document is intended to help you understand how |
| 8 | +you can do that. |
| 9 | + |
| 10 | +## Project roles |
| 11 | + |
| 12 | +We greatly appreciate everyone's contributions, and Jujutsu has benefited |
| 13 | +greatly from people who shared a single idea, change, or a suggestion, without |
| 14 | +ever becoming a regular contributor. We also want everybody to feel welcome to |
| 15 | +share their suggestions for the project (as long as you follow the Community |
| 16 | +Guidelines). |
| 17 | + |
| 18 | +There are two special roles for participants in the Jujutsu projects: |
| 19 | +Maintainers and Contributors. |
| 20 | + |
| 21 | +The role of the Maintainer is formally defined. These are the people empowered |
| 22 | +to collectively make final decisions about most aspects of the project. They are |
| 23 | +expected to take community's input seriously and to aim for the benefit of the |
| 24 | +entire community. |
| 25 | + |
| 26 | +The role of a Contributor is less formal. In situations where opinions become |
| 27 | +numerous or contentious, it is acceptable for the maintainers to assign more |
| 28 | +weight to the voices of the more established Contributors. |
| 29 | + |
| 30 | +### Maintainers |
| 31 | + |
| 32 | +**Maintainers** are the people who contribute, review, guide, and collectively |
| 33 | +make decisions about the direction and scope of the project (see: |
| 34 | +[Decision Making](#decision-making)). Maintainers are elected by a |
| 35 | +[voting process](#adding-and-removing-maintainers). |
| 36 | + |
| 37 | +A typical Maintainer is not only someone who has made "large" contributions, but |
| 38 | +someone who has shown they are continuously committed to the project and its |
| 39 | +community. Some expected responsibilities of maintainers include (but are not |
| 40 | +exclusively limited to): |
| 41 | + |
| 42 | +- Displaying a high level of commitment to the project and its community, and |
| 43 | + being a role model for others. |
| 44 | +- Writing patches — a lot of patches, especially "glue code" or "grunt |
| 45 | + work" or general "housekeeping"; fixing bugs, ensuring documentation is always |
| 46 | + high quality, consistent UX design, improving processes, making judgments on |
| 47 | + dependencies, handling security vulnerabilities, and so on and so forth. |
| 48 | +- Reviewing code submitted by others — with an eye to maintainability, |
| 49 | + performance, code quality, and "style" (fitting in with the project). |
| 50 | +- Participating in design discussions, especially with regards to architecture |
| 51 | + or long-term vision. |
| 52 | +- Ensuring the community remains a warm and welcoming place, to new and veteran |
| 53 | + members alike. |
| 54 | + |
| 55 | +This is not an exhaustive list, nor is it intended that every Maintainer does |
| 56 | +each and every one of these individual tasks to equal amounts. Rather this is |
| 57 | +only a guideline for what Maintainers are expected to conceptually do. |
| 58 | + |
| 59 | +In short, Maintainers are the outwardly visible stewards of the project. |
| 60 | + |
| 61 | +#### Current list of Maintainers |
| 62 | + |
| 63 | +The current list of Maintainers: |
| 64 | + |
| 65 | +- Austin Seipp (@thoughtpolice) |
| 66 | +- Ilya Grigoriev (@ilyagr) |
| 67 | +- Martin von Zweigbergk (@martinvonz) |
| 68 | +- Waleed Khan (@arxanas) |
| 69 | +- Yuya Nishihara (@yuja) |
| 70 | + |
| 71 | +### Contributors |
| 72 | + |
| 73 | +We consider contributors to be active participants in the project and community |
| 74 | +who are _not_ maintainers. These are people who might: |
| 75 | + |
| 76 | +- Help users by answering questions |
| 77 | +- Participating in lively and respectful discussions across various channels |
| 78 | +- Submit high-quality bug reports, reproduce reported bugs, and verifying fixes |
| 79 | +- Submit patches or pull requests |
| 80 | +- Provide reviews and input on others' pull requests |
| 81 | +- Help with testing and quality assurance |
| 82 | +- Submit feedback about planned features, use cases, or bugs |
| 83 | + |
| 84 | +We essentially define them as **people who actively participate in the |
| 85 | +project**. Examples of things that would _not_ make you a contributor are: |
| 86 | + |
| 87 | +- Submitting a single bug report and never returning |
| 88 | +- Writing blog posts or other evangelism |
| 89 | +- Using the software in production |
| 90 | +- Forking the project and maintaining your own version |
| 91 | +- Writing a third-party tool or add-on |
| 92 | + |
| 93 | +While these are all generally quite valuable, we don't consider these ongoing |
| 94 | +contributions to the codebase or project itself, and on their own do not |
| 95 | +constitute "active participation". |
| 96 | + |
| 97 | +## Processes |
| 98 | + |
| 99 | +For the purposes of making decisions across the project, the following processes |
| 100 | +are defined. |
| 101 | + |
| 102 | +### Decision-Making |
| 103 | + |
| 104 | +The person proposing a decision to be made (i.e. technical, project direction, |
| 105 | +etc.) can offer a proposal, along with a 2-to-4 week deadline for discussion. |
| 106 | +During this time, Maintainers may participate with a vote of: |
| 107 | + |
| 108 | +A) Support B) Reject C) Abstain |
| 109 | + |
| 110 | +Each Maintainer gets one vote. The total number of "participating votes" is the |
| 111 | +number of Maintainer votes which are not Abstain. The proposal is accepted when |
| 112 | +more than half of the participating votes are Support. |
| 113 | + |
| 114 | +In the event that a decision is reached before the proposed timeline, said |
| 115 | +proposal can move on and be accepted immediately. In the event no consensus is |
| 116 | +reached, a proposal may be re-submitted later on. |
| 117 | + |
| 118 | +This document itself is subject to the Decision-Making process by the existing |
| 119 | +set of Maintainers. |
| 120 | + |
| 121 | +### Adding and Removing Maintainers |
| 122 | + |
| 123 | +An active Contributor may, at any given time, nominate themselves or another |
| 124 | +Contributor to become a Maintainer. This process is purely optional and no |
| 125 | +Contributor is expected to do so; however, self-nomination is encouraged for |
| 126 | +active participants. A vote and discussion by the existing Maintainers will be |
| 127 | +used to decide the outcome. |
| 128 | + |
| 129 | +Note that Contributors should demonstrate a high standard of continuous |
| 130 | +participation to become a Maintainer; the upper limit on the number of |
| 131 | +Maintainers is practically bounded, and so rejection should be considered as a |
| 132 | +real possibility. As the scope of the project changes, this limit may increase, |
| 133 | +but it is fundamentally fluid. (If you are unsure, you are free to privately ask |
| 134 | +existing Maintainers before self-nominating if there is room.) |
| 135 | + |
| 136 | +A Maintainer may, at any time, cede their responsibility and step down without a |
| 137 | +vote. |
| 138 | + |
| 139 | +A Maintainer can be removed by other Maintainers, subject to a vote of at-least |
| 140 | +a 2/3rds majority from the existing Maintainer group (excluding the vote of the |
| 141 | +Maintainer in question). This can be due to lack of participation or conduct |
| 142 | +violations, among other things. Note that Maintainers are subject to a higher |
| 143 | +set of behavioral and communicative standards than average contributor or |
| 144 | +participant. |
0 commit comments