1# distribution/reference Project Governance
2
3Distribution [Code of Conduct](./CODE-OF-CONDUCT.md) can be found here.
4
5For specific guidance on practical contribution steps please
6see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide.
7
8## Maintainership
9
10There are different types of maintainers, with different responsibilities, but
11all maintainers have 3 things in common:
12
131) They share responsibility in the project's success.
142) They have made a long-term, recurring time investment to improve the project.
153) They spend that time doing whatever needs to be done, not necessarily what
16is the most interesting or fun.
17
18Maintainers are often under-appreciated, because their work is harder to appreciate.
19It's easy to appreciate a really cool and technically advanced feature. It's harder
20to appreciate the absence of bugs, the slow but steady improvement in stability,
21or the reliability of a release process. But those things distinguish a good
22project from a great one.
23
24## Reviewers
25
26A reviewer is a core role within the project.
27They share in reviewing issues and pull requests and their LGTM counts towards the
28required LGTM count to merge a code change into the project.
29
30Reviewers are part of the organization but do not have write access.
31Becoming a reviewer is a core aspect in the journey to becoming a maintainer.
32
33## Adding maintainers
34
35Maintainers are first and foremost contributors that have shown they are
36committed to the long term success of a project. Contributors wanting to become
37maintainers are expected to be deeply involved in contributing code, pull
38request review, and triage of issues in the project for more than three months.
39
40Just contributing does not make you a maintainer, it is about building trust
41with the current maintainers of the project and being a person that they can
42depend on and trust to make decisions in the best interest of the project.
43
44Periodically, the existing maintainers curate a list of contributors that have
45shown regular activity on the project over the prior months. From this list,
46maintainer candidates are selected and proposed in a pull request or a
47maintainers communication channel.
48
49After a candidate has been announced to the maintainers, the existing
50maintainers are given five business days to discuss the candidate, raise
51objections and cast their vote. Votes may take place on the communication
52channel or via pull request comment. Candidates must be approved by at least 66%
53of the current maintainers by adding their vote on the mailing list. The
54reviewer role has the same process but only requires 33% of current maintainers.
55Only maintainers of the repository that the candidate is proposed for are
56allowed to vote.
57
58If a candidate is approved, a maintainer will contact the candidate to invite
59the candidate to open a pull request that adds the contributor to the
60MAINTAINERS file. The voting process may take place inside a pull request if a
61maintainer has already discussed the candidacy with the candidate and a
62maintainer is willing to be a sponsor by opening the pull request. The candidate
63becomes a maintainer once the pull request is merged.
64
65## Stepping down policy
66
67Life priorities, interests, and passions can change. If you're a maintainer but
68feel you must remove yourself from the list, inform other maintainers that you
69intend to step down, and if possible, help find someone to pick up your work.
70At the very least, ensure your work can be continued where you left off.
71
72After you've informed other maintainers, create a pull request to remove
73yourself from the MAINTAINERS file.
74
75## Removal of inactive maintainers
76
77Similar to the procedure for adding new maintainers, existing maintainers can
78be removed from the list if they do not show significant activity on the
79project. Periodically, the maintainers review the list of maintainers and their
80activity over the last three months.
81
82If a maintainer has shown insufficient activity over this period, a neutral
83person will contact the maintainer to ask if they want to continue being
84a maintainer. If the maintainer decides to step down as a maintainer, they
85open a pull request to be removed from the MAINTAINERS file.
86
87If the maintainer wants to remain a maintainer, but is unable to perform the
88required duties they can be removed with a vote of at least 66% of the current
89maintainers. In this case, maintainers should first propose the change to
90maintainers via the maintainers communication channel, then open a pull request
91for voting. The voting period is five business days. The voting pull request
92should not come as a surpise to any maintainer and any discussion related to
93performance must not be discussed on the pull request.
94
95## How are decisions made?
96
97Docker distribution is an open-source project with an open design philosophy.
98This means that the repository is the source of truth for EVERY aspect of the
99project, including its philosophy, design, road map, and APIs. *If it's part of
100the project, it's in the repo. If it's in the repo, it's part of the project.*
101
102As a result, all decisions can be expressed as changes to the repository. An
103implementation change is a change to the source code. An API change is a change
104to the API specification. A philosophy change is a change to the philosophy
105manifesto, and so on.
106
107All decisions affecting distribution, big and small, follow the same 3 steps:
108
109* Step 1: Open a pull request. Anyone can do this.
110
111* Step 2: Discuss the pull request. Anyone can do this.
112
113* Step 3: Merge or refuse the pull request. Who does this depends on the nature
114of the pull request and which areas of the project it affects.
115
116## Helping contributors with the DCO
117
118The [DCO or `Sign your work`](./CONTRIBUTING.md#sign-your-work)
119requirement is not intended as a roadblock or speed bump.
120
121Some contributors are not as familiar with `git`, or have used a web
122based editor, and thus asking them to `git commit --amend -s` is not the best
123way forward.
124
125In this case, maintainers can update the commits based on clause (c) of the DCO.
126The most trivial way for a contributor to allow the maintainer to do this, is to
127add a DCO signature in a pull requests's comment, or a maintainer can simply
128note that the change is sufficiently trivial that it does not substantially
129change the existing contribution - i.e., a spelling change.
130
131When you add someone's DCO, please also add your own to keep a log.
132
133## I'm a maintainer. Should I make pull requests too?
134
135Yes. Nobody should ever push to master directly. All changes should be
136made through a pull request.
137
138## Conflict Resolution
139
140If you have a technical dispute that you feel has reached an impasse with a
141subset of the community, any contributor may open an issue, specifically
142calling for a resolution vote of the current core maintainers to resolve the
143dispute. The same voting quorums required (2/3) for adding and removing
144maintainers will apply to conflict resolution.
View as plain text