Cleanup MAINTAINERS file

This removes sections from the maintainers file
that have been moved to the https://github.com/docker/opensource
repository.

Also replaces spaces for tabs for consistency (yay ocd).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

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"