You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+16-58Lines changed: 16 additions & 58 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,10 @@
3
3
Want to hack on Docker? Awesome! Here are instructions to get you started. They are probably not perfect, please let us know if anything feels
4
4
wrong or incomplete.
5
5
6
+
## Build Environment
7
+
8
+
For instructions on setting up your development environment, please see our dedicated [dev environment setup docs](http://docs.docker.io/en/latest/contributing/devenvironment/).
9
+
6
10
## Contribution guidelines
7
11
8
12
### Pull requests are always welcome
@@ -55,8 +59,10 @@ Submit unit tests for your changes. Go has a great test framework built in; use
55
59
it! Take a look at existing tests for inspiration. Run the full test suite on
56
60
your branch before submitting a pull request.
57
61
58
-
Make sure you include relevant updates or additions to documentation when
59
-
creating or modifying features.
62
+
Update the documentation when creating or modifying features. Test
63
+
your documentation changes for clarity, concision, and correctness, as
64
+
well as a clean docmuent build. See ``docs/README.md`` for more
65
+
information on building the docs and how docs get released.
and maintenance. Always run `go fmt` before committing your changes. Most
@@ -89,53 +95,17 @@ name and email address match your git configuration. The AUTHORS file is
89
95
regenerated occasionally from the git commit history, so a mismatch may result
90
96
in your changes being overwritten.
91
97
98
+
### Approval
92
99
93
-
## Decision process
94
-
95
-
### How are decisions made?
96
-
97
-
Short answer: with pull requests to the docker repository.
98
-
99
-
Docker is an open-source project with an open design philosophy. This means that the repository is the source of truth for EVERY aspect of the project,
100
-
including its philosophy, design, roadmap and APIs. *If it's part of the project, it's in the repo. It's in the repo, it's part of the project.*
101
-
102
-
As a result, all decisions can be expressed as changes to the repository. An implementation change is a change to the source code. An API change is a change to
103
-
the API specification. A philosophy change is a change to the philosophy manifesto. And so on.
104
-
105
-
All decisions affecting docker, big and small, follow the same 3 steps:
106
-
107
-
* Step 1: Open a pull request. Anyone can do this.
108
-
109
-
* Step 2: Discuss the pull request. Anyone can do this.
110
-
111
-
* Step 3: Accept or refuse a pull request. The relevant maintainer does this (see below "Who decides what?")
112
-
113
-
114
-
### Who decides what?
115
-
116
-
So all decisions are pull requests, and the relevant maintainer makes the decision by accepting or refusing the pull request.
117
-
But how do we identify the relevant maintainer for a given pull request?
100
+
Docker maintainers use LGTM (looks good to me) in comments on the code review
101
+
to indicate acceptance.
118
102
119
-
Docker follows the timeless, highly efficient and totally unfair system known as [Benevolent dictator for life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life),
120
-
with yours truly, Solomon Hykes, in the role of BDFL.
121
-
This means that all decisions are made by default by me. Since making every decision myself would be highly unscalable, in practice decisions are spread across multiple maintainers.
103
+
A change requires LGTMs from an absolute majority of the maintainers of each
104
+
component affected. For example, if a change affects docs/ and registry/, it
105
+
needs an absolute majority from the maintainers of docs/ AND, separately, an
106
+
absolute majority of the maintainers of registry
122
107
123
-
The relevant maintainer for a pull request is assigned in 3 steps:
124
-
125
-
* Step 1: Determine the subdirectory affected by the pull request. This might be src/registry, docs/source/api, or any other part of the repo.
126
-
127
-
* Step 2: Find the MAINTAINERS file which affects this directory. If the directory itself does not have a MAINTAINERS file, work your way up the the repo hierarchy until you find one.
128
-
129
-
* Step 3: The first maintainer listed is the primary maintainer. The pull request is assigned to him. He may assign it to other listed maintainers, at his discretion.
130
-
131
-
132
-
### I'm a maintainer, should I make pull requests too?
133
-
134
-
Primary maintainers are not required to create pull requests when changing their own subdirectory, but secondary maintainers are.
135
-
136
-
### Who assigns maintainers?
137
-
138
-
Solomon.
108
+
For more details see [MAINTAINERS.md](hack/MAINTAINERS.md)
139
109
140
110
### How can I become a maintainer?
141
111
@@ -146,15 +116,3 @@ Solomon.
146
116
Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available.
147
117
You don't have to be a maintainer to make a difference on the project!
148
118
149
-
### What are a maintainer's responsibility?
150
-
151
-
It is every maintainer's responsibility to:
152
-
153
-
*1) Expose a clear roadmap for improving their component.
154
-
*2) Deliver prompt feedback and decisions on pull requests.
155
-
*3) Be available to anyone with questions, bug reports, criticism etc. on their component. This includes irc, github requests and the mailing list.
156
-
*4) Make sure their component respects the philosophy, design and roadmap of the project.
157
-
158
-
### How is this process changed?
159
-
160
-
Just like everything else: by making a pull request :)
0 commit comments