Merge pull request #18321 from icecrime/maintainers_rework

MAINTAINERS file cleanup

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
@@ -256,13 +219,16 @@ made through a pull request.
 
 		people = [
 			"calavera",
+			"cpuguy83",
 			"crosbymichael",
+			"duglin",
 			"erikh",
 			"estesp",
 			"icecrime",
 			"jfrazelle",
 			"lk4d4",
 			"runcom",
+			"tianon",
 			"tibor",
 			"unclejack",
 			"vbatts",
@@ -271,127 +237,16 @@ made through a pull request.
 			"vishh"
 		]
 
-	[Org.Subsystems]
+    [Org."Docs maintainers"]
 
-	# 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.Subsystems.Documentation]
-
-			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"
-			]
+    # TODO Describe the docs maintainers role.
+
+        people = [
+            "jamtur01",
+            "moxiegirl",
+            "sven",
+            "thajeztah"
+        ]
 
 	[Org.Curators]
 
@@ -493,6 +348,11 @@ made through a pull request.
 	Email = "arnaud@docker.com"
 	GitHub = "icecrime"
 
+	[people.jamtur01]
+	Name = "James Turnbull"
+	Email = "james@lovedthanlost.net"
+	GitHub = "jamtur01"
+
 	[people.jfrazelle]
 	Name = "Jessie Frazelle"
 	Email = "j@docker.com"