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