diff --git a/MAINTAINERS b/MAINTAINERS index c7692e7dce..abcebe4960 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,206 +1,16 @@ # Docker maintainers file # -# This file describes who runs the Docker project and how. -# This is a living document - if you see something out of date or missing, -# speak up! +# This file describes who runs the docker/docker project and how. +# This is a living document - if you see something out of date or missing, speak up! # # It is structured to be consumable by both humans and programs. # To extract its contents programmatically, use any TOML-compliant # parser. - -[Rules] - - [Rules.maintainers] - - title = "What is a maintainer?" - - text = """ -There are different types of maintainers, with different responsibilities, but -all maintainers have 3 things in common: - -1) They share responsibility in the project's success. -2) They have made a long-term, recurring time investment to improve the project. -3) They spend that time doing whatever needs to be done, not necessarily what -is the most interesting or fun. - -Maintainers are often under-appreciated, because their work is harder to appreciate. -It's easy to appreciate a really cool and technically advanced feature. It's harder -to appreciate the absence of bugs, the slow but steady improvement in stability, -or the reliability of a release process. But those things distinguish a good -project from a great one. -""" - - [Rules.bdfl] - - title = "The Benevolent dictator for life (BDFL)" - - text = """ -Docker follows the timeless, highly efficient and totally unfair system -known as [Benevolent dictator for -life](https://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 Solomon. Since making every decision -myself would be highly un-scalable, in practice decisions are spread -across multiple maintainers. - -Ideally, the BDFL role is like the Queen of England: awesome crown, but not -an actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY. -Every other rule can change, perhaps drastically so, but the BDFL will always -be there, preserving the philosophy and principles of the project, and keeping -ultimate authority over its fate. This gives us great flexibility in experimenting -with various governance models, knowing that we can always press the "reset" button -without fear of fragmentation or deadlock. See the US congress for a counter-example. - -BDFL daily routine: - -* Is the project governance stuck in a deadlock or irreversibly fragmented? - * If yes: refactor the project governance -* Are there issues or conflicts escalated by core? - * If yes: resolve them -* Go back to polishing that crown. -""" - - [Rules.decisions] - - title = "How are decisions made?" - - text = """ -Short answer: EVERYTHING IS A PULL REQUEST. - -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, road map, and APIs. *If it's -part of the project, it's in the repo. If 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: Merge or refuse the pull request. Who does this depends on the nature -of the pull request and which areas of the project it affects. See *review flow* -for details. - -Because Docker is such a large and active project, it's important for everyone to know -who is responsible for deciding what. That is determined by a precise set of rules. - -* For every *decision* in the project, the rules should designate, in a deterministic way, -who should *decide*. - -* For every *problem* in the project, the rules should designate, in a deterministic way, -who should be responsible for *fixing* it. - -* For every *question* in the project, the rules should designate, in a deterministic way, -who should be expected to have the *answer*. -""" - - [Rules.review] - - title = "Review flow" - - text = """ -Pull requests should be processed according to the following flow: - -* For each subsystem affected by the change, the maintainers of the subsystem must approve or refuse it. -It is the responsibility of the subsystem maintainers to process patches affecting them in a timely -manner. - -* If the change affects areas of the code which are not part of a subsystem, -or if subsystem maintainers are unable to reach a timely decision, it must be approved by -the core maintainers. - -* If the change affects the UI or public APIs, or if it represents a major change in architecture, -the architects must approve or refuse it. - -* If the change affects the operations of the project, it must be approved or rejected by -the relevant operators. - -* If the change affects the governance, philosophy, goals or principles of the project, -it must be approved by BDFL. -""" - - [Rules.DCO] - - title = "Helping contributors with the DCO" - - text = """ -The [DCO or `Sign your work`]( -https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work) -requirement is not intended as a roadblock or speed bump. - -Some Docker contributors are not as familiar with `git`, or have used a web based -editor, and thus asking them to `git commit --amend -s` is not the best way forward. - -In this case, maintainers can update the commits based on clause (c) of the DCO. The -most trivial way for a contributor to allow the maintainer to do this, is to add -a DCO signature in a Pull Requests's comment, or a maintainer can simply note that -the change is sufficiently trivial that it does not substantially change the existing -contribution - i.e., a spelling change. - -When you add someone's DCO, please also add your own to keep a log. -""" - - [Rules.holiday] - - title = "I'm a maintainer, and I'm going on holiday" - - text = """ -Please let your co-maintainers and other contributors know by raising a pull -request that comments out your `MAINTAINERS` file entry using a `#`. -""" - - [Rules."no direct push"] - - title = "I'm a maintainer. Should I make pull requests too?" - - text = """ -Yes. Nobody should ever push to master directly. All changes should be -made through a pull request. -""" - - [Rules.meta] - - title = "How is this process changed?" - - text = "Just like everything else: by making a pull request :)" - -# Current project organization +# +# This file is compiled into the MAINTAINERS file in docker/opensource. +# [Org] - bdfl = "shykes" - - # The chief architect is responsible for the overall integrity of the technical architecture - # across all subsystems, and the consistency of APIs and UI. - # - # Changes to UI, public APIs and overall architecture (for example a plugin system) must - # be approved by the chief architect. - "Chief Architect" = "shykes" - - # The chief maintainer is responsible for all aspects of quality for the project including - # code reviews, usability, stability, security, performance, etc. - # The most important function of the chief maintainer is to lead by example. On the first - # day of a new maintainer, the best advice should be "follow the C.M.'s example and you'll - # be fine". - "Chief Maintainer" = "crosbymichael" - - # The community manager is responsible for serving the project community, including users, - # contributors and partners. This involves: - # - facilitating communication between maintainers, contributors and users - # - organizing contributor and maintainer events - # - helping new contributors get involved - # - anything the project community needs to be successful - # - # The community manager is a point of contact for any contributor who has questions, concerns - # or feedback about project operations. - "Community Manager" = "theadactyl" - [Org."Core maintainers"] # The Core maintainers are the ghostbusters of the project: when there's a problem others @@ -214,8 +24,6 @@ made through a pull request. # For each release (including minor releases), a "release captain" is assigned from the # pool of core maintainers. Rotation is encouraged across all maintainers, to ensure # the release process is clear and up-to-date. - # - # It is common for core maintainers to "branch out" to join or start a subsystem. people = [ "calavera", @@ -237,16 +45,16 @@ made through a pull request. "vishh" ] - [Org."Docs maintainers"] + [Org."Docs maintainers"] - # TODO Describe the docs maintainers role. + # TODO Describe the docs maintainers role. - people = [ - "jamtur01", - "moxiegirl", - "sven", - "thajeztah" - ] + people = [ + "jamtur01", + "moxiegirl", + "sven", + "thajeztah" + ] [Org.Curators] @@ -260,9 +68,9 @@ made through a pull request. # - close an issue or pull request when it's an exact duplicate # - close an issue or pull request when it's inappropriate or off-topic - people = [ - "thajeztah" - ] + people = [ + "thajeztah" + ] [people] @@ -272,6 +80,7 @@ made through a pull request. # in the people section. # ADD YOURSELF HERE IN ALPHABETICAL ORDER + [people.calavera] Name = "David Calavera" Email = "david.calavera@gmail.com"