MAINTAINERS file cleanup

First phase in cleaning up the MAINTAINERS file to make it better
reflect reality by:

- Removing "Operators" that have no practical role.
- Removing "Subsystems" as they often are separate repositories with
  their own MAINTAINERS files.

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>

MAINTAINERS

@@ -183,43 +183,6 @@ made through a pull request.
 	# be approved by the chief architect.
 	"Chief Architect" = "shykes"
 
-	[Org.Operators]
-
-	# The operators make sure the trains run on time. They are responsible for overall operations
-	# of the project. This includes facilitating communication between all the participants; helping
-	# newcomers get involved and become successful contributors and maintainers; tracking the schedule
-	# of releases; managing the relationship with downstream distributions and upstream dependencies;
-	# define measures of success for the project and measure progress; Devise and implement tools and
-	# processes which make contributors and maintainers happier and more efficient.
-
-
-		[Org.Operators.security]
-
-			people = [
-				"erw",
-				"diogomonica",
-				"nathanmccauley"
-			]
-
-		[Org.Operators."monthly meetings"]
-
-			people = [
-				"sven",
-				"tianon"
-			]
-
-		[Org.Operators.infrastructure]
-
-			people = [
-				"jfrazelle",
-				"crosbymichael"
-			]
-
-		[Org.Operators.community]
-			people = [
-				"theadactyl"
-			]
-
 	# 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
@@ -271,127 +234,18 @@ made through a pull request.
 			"vishh"
 		]
 
-	[Org.Subsystems]
 
-	# As the project grows, it gets separated into well-defined subsystems. Each subsystem
-	# has a dedicated group of maintainers, which are dedicated to that subsytem and responsible
-	# for its quality.
-	# This "cellular division" is the primary mechanism for scaling maintenance of the project as it grows.
-	#
-	# The maintainers of each subsytem are responsible for:
-	#
-	# 1. Exposing a clear road map for improving their subsystem.
-	# 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem.
-	# 3. Be available to anyone with questions, bug reports, criticism etc.
-	#	on their component. This includes IRC, GitHub requests and the mailing
-	#	list.
-	# 4. Make sure their subsystem respects the philosophy, design and
-	#	road map of the project.
-	#
-	# #### How to review patches to your subsystem
-	#
-	# Accepting pull requests:
-	#
-	#	- If the pull request appears to be ready to merge, give it a `LGTM`, which
-	#	  stands for "Looks Good To Me".
-	#	- If the pull request has some small problems that need to be changed, make
-	#	  a comment adressing the issues.
-	#	- If the changes needed to a PR are small, you can add a "LGTM once the
-	#	  following comments are addressed..." this will reduce needless back and
-	#	  forth.
-	#	- If the PR only needs a few changes before being merged, any MAINTAINER can
-	#	  make a replacement PR that incorporates the existing commits and fixes the
-	#	  problems before a fast track merge.
-	#
-	# Closing pull requests:
-	#
-	#	- If a PR appears to be abandoned, after having attempted to contact the
-	#	  original contributor, then a replacement PR may be made. Once the
-	#	  replacement PR is made, any contributor may close the original one.
-	#	- If you are not sure if the pull request implements a good feature or you
-	#	  do not understand the purpose of the PR, ask the contributor to provide
-	#	  more documentation.  If the contributor is not able to adequately explain
-	#	  the purpose of the PR, the PR may be closed by any MAINTAINER.
-	#	- If a MAINTAINER feels that the pull request is sufficiently architecturally
-	#	  flawed, or if the pull request needs significantly more design discussion
-	#	  before being considered, the MAINTAINER should close the pull request with
-	#	  a short explanation of what discussion still needs to be had.  It is
-	#	  important not to leave such pull requests open, as this will waste both the
-	#	  MAINTAINER's time and the contributor's time.  It is not good to string a
-	#	  contributor on for weeks or months, having them make many changes to a PR
-	#	  that will eventually be rejected.
+    [Org."Docs maintainers"]
 
-		[Org.Subsystems.Documentation]
+    # TODO Describe the docs maintainers role.
 
-			people = [
-				"james",
-				"moxiegirl",
-				"thaJeztah",
-				"jamtur01",
-				"sven"
-			]
-
-		[Org.Subsystems.libcontainer]
-
-			people = [
-				"crosbymichael",
-				"jnagal",
-				"lk4d4",
-				"mpatel",
-				"vmarmol"
-			]
-
-		[Org.Subsystems.registry]
-
-			people = [
-				"dmcg",
-				"dmp42",
-				"jlhawn",
-				"samalba",
-				"sday",
-				"vbatts"
-			]
-
-		[Org.Subsystems."build tools"]
-
-			people = [
-				"shykes",
-				"tianon"
-			]
-
-		[Org.Subsystem."remote api"]
-
-			people = [
-				"vieux"
-			]
-
-		[Org.Subsystem.swarm]
-
-			people = [
-				"aluzzardi",
-				"vieux"
-			]
-
-		[Org.Subsystem.machine]
-
-			people = [
-				"bfirsh",
-				"ehazlett"
-			]
-
-		[Org.Subsystem.compose]
-
-			people = [
-				"aanand"
-			]
-
-		[Org.Subsystem.builder]
-
-			people = [
-				"duglin",
-				"erikh",
-				"tibor"
-			]
+        people = [
+            "james",
+            "moxiegirl",
+            "thajeztah",
+            "jamtur01",
+            "sven"
+        ]
 
 	[Org.Curators]