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
- Practicing transparency in the project, communicating decisions and their
55
rationale when appropriate.
56
57
This is not an exhaustive list, nor is it intended that every Maintainer does
58
each and every one of these individual tasks to equal amounts. Rather this is
59
only a guideline for what Maintainers are expected to conceptually do.
60
61
In short, Maintainers are the outwardly visible stewards of the project.
62
63
#### Current list of Maintainers
64
65
The current list of Maintainers:
66
67
- Austin Seipp (@thoughtpolice)
68
- Benjamin Tan (@bnjmnt4n)
69
- Ilya Grigoriev (@ilyagr)
70
- Martin von Zweigbergk (@martinvonz)
71
- Scott Taylor (@scott2000)
72
- Waleed Khan (@arxanas)
73
- Yuya Nishihara (@yuja)
74
75
### Contributors
76
77
We consider contributors to be active participants in the project and community
78
who are _not_ maintainers. These are people who might:
79
80
- Help users by answering questions
81
- Participating in lively and respectful discussions across various channels
82
- Submit high-quality bug reports, reproduce reported bugs, and verifying fixes
83
- Submit patches or pull requests
84
- Provide reviews and input on others' pull requests
85
- Help with testing and quality assurance
86
- Submit feedback about planned features, use cases, or bugs
87
88
We essentially define them as **people who actively participate in the
89
project**. Examples of things that would _not_ make you a contributor are:
90
91
- Submitting a single bug report and never returning
92
- Writing blog posts or other evangelism
93
- Using the software in production
94
- Forking the project and maintaining your own version
95
- Writing a third-party tool or add-on
96
97
While these are all generally quite valuable, we don't consider these ongoing
98
contributions to the codebase or project itself, and on their own do not
99
constitute "active participation".
100
101
## Processes
102
103
For the purposes of making decisions across the project, the following processes
104
are defined.
105
106
### Decision-Making
107
108
The person proposing a decision to be made (i.e. technical, project direction,
109
etc.) can offer a proposal, along with a 2-to-4 week deadline for discussion.
110
During this time, Maintainers may participate with a vote of:
111
112
A) Support B) Reject C) Abstain
113
114
Each Maintainer gets one vote. The total number of "participating votes" is the
115
number of Maintainer votes which are not Abstain. The proposal is accepted when
116
more than half of the participating votes are Support.
117
118
In the event that a decision is reached before the proposed timeline, said
119
proposal can move on and be accepted immediately. In the event no consensus is
120
reached, a proposal may be re-submitted later on.
121
122
This document itself is subject to the Decision-Making process by the existing
123
set of Maintainers.
124
125
### Adding and Removing Maintainers
126
127
An active Contributor may, at any given time, nominate themselves or another
128
Contributor to become a Maintainer. This process is purely optional and no
129
Contributor is expected to do so; however, self-nomination is encouraged for
130
active participants. A vote and discussion by the existing Maintainers will be
131
used to decide the outcome.
132
133
Note that Contributors should demonstrate a high standard of continuous
134
participation to become a Maintainer; the upper limit on the number of
135
Maintainers is practically bounded, and so rejection should be considered as a
136
real possibility. As the scope of the project changes, this limit may increase,
137
but it is fundamentally fluid. (If you are unsure, you are free to privately ask
138
existing Maintainers before self-nominating if there is room.)
139
140
A Maintainer may, at any time, cede their responsibility and step down without a
141
vote.
142
143
A Maintainer can be removed by other Maintainers, subject to a vote of at-least
144
a 2/3rds majority from the existing Maintainer group (excluding the vote of the
145
Maintainer in question). This can be due to lack of participation or conduct
146
violations, among other things. Note that Maintainers are subject to a higher
147
set of behavioral and communicative standards than average contributor or
148
participant.
149
150
### Single-Company Influence
151
152
At most 1/3 of the maintainers may be paid for their contributions by a single
153
company. This is to reduce the risk of a single company controlling the
154
project's direction. If the 1/3 limit gets exceeded because an existing
155
maintainer gets hired by the same company as some other existing maintainer(s),
156
then the maintainers will have to decide how to resolve the situation. The
157
maintainer in question gets to vote, as long as this doesn't mean the company
158
in question has half the votes (usually meaning there are at least 5 maintainers
159
total).
160
