ilyagr.bsky.social
+144
GOVERNANCE.md
+144
GOVERNANCE.md
···
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.
+1
docs/governance/GOVERNANCE.md
+1
docs/governance/GOVERNANCE.md
···
1
+
../../GOVERNANCE.md
+1
mkdocs.yml
+1
mkdocs.yml
···
137
137
- 'Design Doc Blueprint': 'design_doc_blueprint.md'
138
138
- 'Releasing': 'releasing.md'
139
139
- 'Temporary Voting for Governance': 'governance/temporary-voting.md'
140
+
- 'Governance': 'governance/GOVERNANCE.md'
140
141
141
142
- 'Design docs':
142
143
- 'git-submodules': 'design/git-submodules.md'