1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00

Documented who decides what and how.

This commit is contained in:
Solomon Hykes 2013-05-28 19:39:09 -07:00
parent 522f399d68
commit 24ddfe3f25
13 changed files with 89 additions and 0 deletions

View file

@ -1,3 +1,8 @@
# This file lists all individuals having contributed content to the repository.
# If you're submitting a patch, please add your name here in alphabetical order as part of the patch.
#
# For a list of active project maintainers, see the MAINTAINERS file.
#
Al Tobey <al@ooyala.com> Al Tobey <al@ooyala.com>
Alexey Shamrin <shamrin@gmail.com> Alexey Shamrin <shamrin@gmail.com>
Andrea Luzzardi <aluzzardi@gmail.com> Andrea Luzzardi <aluzzardi@gmail.com>

View file

@ -88,3 +88,72 @@ Add your name to the AUTHORS file, but make sure the list is sorted and your
name and email address match your git configuration. The AUTHORS file is name and email address match your git configuration. The AUTHORS file is
regenerated occasionally from the git commit history, so a mismatch may result regenerated occasionally from the git commit history, so a mismatch may result
in your changes being overwritten. in your changes being overwritten.
## Decision process
### How are decisions made?
Short answer: with pull requests to the docker repository.
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,
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.*
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
the API specification. A philosophy change is a change to the philosophy manifesto. And so on.
All decisions affecting docker, big and small, follow the same 3 steps:
* Step 1: Open a pull request. Anyone can do this.
* Step 2: Discuss the pull request. Anyone can do this.
* Step 3: Accept or refuse a pull request. The relevant maintainer does this (see below "Who decides what?")
### Who decides what?
So all decisions are pull requests, and the relevant maintainer makes the decision by accepting or refusing the pull request.
But how do we identify the relevant maintainer for a given pull request?
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),
with yours truly, Solomon Hykes, in the role of BDFL.
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.
The relevant maintainer for a pull request is assigned in 3 steps:
* 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.
* 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.
* 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.
### I'm a maintainer, should I make pull requests too?
Primary maintainers are not required to create pull requests when changing their own subdirectory, but secondary maintainers are.
### Who assigns maintainers?
Solomon.
### How can I become a maintainer?
Step 1: learn the component inside out
Step 2: make yourself useful by contributing code, bugfixes, support etc.
Step 3: volunteer on the irc channel (#docker@freenode)
Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available.
You don't have to be a maintainer to make a difference on the project!
### What are a maintainer's responsibility?
It is every maintainer's responsibility to:
a) be aware of which pull requests they must review, and do so quickly
b) communicate clearly and transparently with other maintainers
c) be available to anyone with questions, bug reports, criticism etc. on their component. This includes irc, github requests and the mailing list.
d) make sure they respect the philosophy and design of the project
### How is this process changed?
Just like everything else: by making a pull request :)

2
MAINTAINERS Normal file
View file

@ -0,0 +1,2 @@
Solomon Hykes <solomon@dotcloud.com>
Guillaume Charmes <guillaume@dotcloud.com>

1
auth/MAINTAINERS Symbolic link
View file

@ -0,0 +1 @@
../registry/MAINTAINERS

1
contrib/MAINTAINERS Normal file
View file

@ -0,0 +1 @@
# Maintainer wanted! Enroll on #docker@freenode

View file

@ -0,0 +1 @@
Solomon Hykes <solomon@dotcloud.com>

2
docs/MAINTAINERS Normal file
View file

@ -0,0 +1,2 @@
Andy Rothfusz <andy@dotcloud.com>
Ken Cochrane <ken@dotcloud.com>

View file

@ -0,0 +1 @@
Solomon Hykes <solomon@dotcloud.com>

1
docs/theme/MAINTAINERS vendored Normal file
View file

@ -0,0 +1 @@
Thatcher Penskens <thatcher@dotcloud.com>

1
docs/website/MAINTAINERS Normal file
View file

@ -0,0 +1 @@
Thatcher Penskens <thatcher@dotcloud.com>

1
packaging/MAINTAINERS Normal file
View file

@ -0,0 +1 @@
Daniel Mizyrycki <daniel@dotcloud.com>

3
registry/MAINTAINERS Normal file
View file

@ -0,0 +1,3 @@
Sam Alba <sam@dotcloud.com>
Joffrey Fuhrer <joffrey@dotcloud.com>
Ken Cochrane <ken@dotcloud.com>

1
testing/MAINTAINERS Normal file
View file

@ -0,0 +1 @@
Daniel Mizyrycki <daniel@dotcloud.com>