@@ -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.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"

-			]

+    [Org."Docs maintainers"]

+

+    # TODO Describe the docs maintainers role.

+

+        people = [

+            "james",

+            "moxiegirl",

+            "thajeztah",

+            "jamtur01",

+            "sven"

+        ]

 	[Org.Curators]