1## Introduction
2
3Dear maintainer. Thank you for investing the time and energy to help
4make runc as useful as possible. Maintaining a project is difficult,
5sometimes unrewarding work. Sure, you will get to contribute cool
6features to the project. But most of your time will be spent reviewing,
7cleaning up, documenting, answering questions, justifying design
8decisions - while everyone has all the fun! But remember - the quality
9of the maintainers work is what distinguishes the good projects from the
10great. So please be proud of your work, even the unglamorous parts,
11and encourage a culture of appreciation and respect for *every* aspect
12of improving the project - not just the hot new features.
13
14This document is a manual for maintainers old and new. It explains what
15is expected of maintainers, how they should work, and what tools are
16available to them.
17
18This is a living document - if you see something out of date or missing,
19speak up!
20
21## What are a maintainer's responsibility?
22
23It is every maintainer's responsibility to:
24
25* 1) Expose a clear roadmap for improving their component.
26* 2) Deliver prompt feedback and decisions on pull requests.
27* 3) Be available to anyone with questions, bug reports, criticism etc.
28 on their component. This includes IRC and GitHub issues and pull requests.
29* 4) Make sure their component respects the philosophy, design and
30 roadmap of the project.
31
32## How are decisions made?
33
34Short answer: with pull requests to the runc repository.
35
36runc is an open-source project with an open design philosophy. This
37means that the repository is the source of truth for EVERY aspect of the
38project, including its philosophy, design, roadmap and APIs. *If it's
39part of the project, it's in the repo. It's in the repo, it's part of
40the project.*
41
42As a result, all decisions can be expressed as changes to the
43repository. An implementation change is a change to the source code. An
44API change is a change to the API specification. A philosophy change is
45a change to the philosophy manifesto. And so on.
46
47All decisions affecting runc, big and small, follow the same 3 steps:
48
49* Step 1: Open a pull request. Anyone can do this.
50
51* Step 2: Discuss the pull request. Anyone can do this.
52
53* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
54this (see below "Who decides what?")
55
56*I'm a maintainer, should I make pull requests too?*
57
58Yes. Nobody should ever push to master directly. All changes should be
59made through a pull request.
60
61## Who decides what?
62
63All decisions are pull requests, and the relevant maintainers make
64decisions by accepting or refusing the pull request. Review and acceptance
65by anyone is denoted by adding a comment in the pull request: `LGTM`.
66However, only currently listed `MAINTAINERS` are counted towards the required
67two LGTMs.
68
69Overall the maintainer system works because of mutual respect across the
70maintainers of the project. The maintainers trust one another to make decisions
71in the best interests of the project. Sometimes maintainers can disagree and
72this is part of a healthy project to represent the point of views of various people.
73In the case where maintainers cannot find agreement on a specific change the
74role of a Chief Maintainer comes into play.
75
76The Chief Maintainer for the project is responsible for overall architecture
77of the project to maintain conceptual integrity. Large decisions and
78architecture changes should be reviewed by the chief maintainer.
79The current chief maintainer for the project is Michael Crosby (@crosbymichael).
80
81Even though the maintainer system is built on trust, if there is a conflict
82with the chief maintainer on a decision, their decision can be challenged
83and brought to the technical oversight board if two-thirds of the
84maintainers vote for an appeal. It is expected that this would be a
85very exceptional event.
86
87
88### How are maintainers added?
89
90The best maintainers have a vested interest in the project. Maintainers
91are first and foremost contributors that have shown they are committed to
92the long term success of the project. Contributors wanting to become
93maintainers are expected to be deeply involved in contributing code,
94pull request review, and triage of issues in the project for more than two months.
95
96Just contributing does not make you a maintainer, it is about building trust
97with the current maintainers of the project and being a person that they can
98depend on and trust to make decisions in the best interest of the project. The
99final vote to add a new maintainer should be approved by over 66% of the current
100maintainers with the chief maintainer having veto power. In case of a veto,
101conflict resolution rules expressed above apply. The voting period is
102five business days on the Pull Request to add the new maintainer.
103
104
105### What is expected of maintainers?
106
107Part of a healthy project is to have active maintainers to support the community
108in contributions and perform tasks to keep the project running. Maintainers are
109expected to be able to respond in a timely manner if their help is required on specific
110issues where they are pinged. Being a maintainer is a time consuming commitment and should
111not be taken lightly.
112
113When a maintainer is unable to perform the required duties they can be removed with
114a vote by 66% of the current maintainers with the chief maintainer having veto power.
115The voting period is ten business days. Issues related to a maintainer's performance should
116be discussed with them among the other maintainers so that they are not surprised by
117a pull request removing them.
118
119
120
View as plain text