@@ -183,43 +183,6 @@ made through a pull request.
183183 # be approved by the chief architect.
184184 "Chief Architect" = "shykes"
185185
186- [Org.Operators]
187-
188- # The operators make sure the trains run on time. They are responsible for overall operations
189- # of the project. This includes facilitating communication between all the participants; helping
190- # newcomers get involved and become successful contributors and maintainers; tracking the schedule
191- # of releases; managing the relationship with downstream distributions and upstream dependencies;
192- # define measures of success for the project and measure progress; Devise and implement tools and
193- # processes which make contributors and maintainers happier and more efficient.
194-
195-
196- [Org.Operators.security]
197-
198- people = [
199- "erw",
200- "diogomonica",
201- "nathanmccauley"
202- ]
203-
204- [Org.Operators."monthly meetings"]
205-
206- people = [
207- "sven",
208- "tianon"
209- ]
210-
211- [Org.Operators.infrastructure]
212-
213- people = [
214- "jfrazelle",
215- "crosbymichael"
216- ]
217-
218- [Org.Operators.community]
219- people = [
220- "theadactyl"
221- ]
222-
223186 # The chief maintainer is responsible for all aspects of quality for the project including
224187 # code reviews, usability, stability, security, performance, etc.
225188 # 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.
271234 "vishh"
272235 ]
273236
274- [Org.Subsystems]
275237
276- # As the project grows, it gets separated into well-defined subsystems. Each subsystem
277- # has a dedicated group of maintainers, which are dedicated to that subsytem and responsible
278- # for its quality.
279- # This "cellular division" is the primary mechanism for scaling maintenance of the project as it grows.
280- #
281- # The maintainers of each subsytem are responsible for:
282- #
283- # 1. Exposing a clear road map for improving their subsystem.
284- # 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem.
285- # 3. Be available to anyone with questions, bug reports, criticism etc.
286- # on their component. This includes IRC, GitHub requests and the mailing
287- # list.
288- # 4. Make sure their subsystem respects the philosophy, design and
289- # road map of the project.
290- #
291- # #### How to review patches to your subsystem
292- #
293- # Accepting pull requests:
294- #
295- # - If the pull request appears to be ready to merge, give it a `LGTM`, which
296- # stands for "Looks Good To Me".
297- # - If the pull request has some small problems that need to be changed, make
298- # a comment adressing the issues.
299- # - If the changes needed to a PR are small, you can add a "LGTM once the
300- # following comments are addressed..." this will reduce needless back and
301- # forth.
302- # - If the PR only needs a few changes before being merged, any MAINTAINER can
303- # make a replacement PR that incorporates the existing commits and fixes the
304- # problems before a fast track merge.
305- #
306- # Closing pull requests:
307- #
308- # - If a PR appears to be abandoned, after having attempted to contact the
309- # original contributor, then a replacement PR may be made. Once the
310- # replacement PR is made, any contributor may close the original one.
311- # - If you are not sure if the pull request implements a good feature or you
312- # do not understand the purpose of the PR, ask the contributor to provide
313- # more documentation. If the contributor is not able to adequately explain
314- # the purpose of the PR, the PR may be closed by any MAINTAINER.
315- # - If a MAINTAINER feels that the pull request is sufficiently architecturally
316- # flawed, or if the pull request needs significantly more design discussion
317- # before being considered, the MAINTAINER should close the pull request with
318- # a short explanation of what discussion still needs to be had. It is
319- # important not to leave such pull requests open, as this will waste both the
320- # MAINTAINER's time and the contributor's time. It is not good to string a
321- # contributor on for weeks or months, having them make many changes to a PR
322- # that will eventually be rejected.
323-
324- [Org.Subsystems.Documentation]
325-
326- people = [
327- "james",
328- "moxiegirl",
329- "thaJeztah",
330- "jamtur01",
331- "sven"
332- ]
333-
334- [Org.Subsystems.libcontainer]
335-
336- people = [
337- "crosbymichael",
338- "jnagal",
339- "lk4d4",
340- "mpatel",
341- "vmarmol"
342- ]
343-
344- [Org.Subsystems.registry]
345-
346- people = [
347- "dmcg",
348- "dmp42",
349- "jlhawn",
350- "samalba",
351- "sday",
352- "vbatts"
353- ]
354-
355- [Org.Subsystems."build tools"]
356-
357- people = [
358- "shykes",
359- "tianon"
360- ]
361-
362- [Org.Subsystem."remote api"]
363-
364- people = [
365- "vieux"
366- ]
367-
368- [Org.Subsystem.swarm]
369-
370- people = [
371- "aluzzardi",
372- "vieux"
373- ]
374-
375- [Org.Subsystem.machine]
376-
377- people = [
378- "bfirsh",
379- "ehazlett"
380- ]
381-
382- [Org.Subsystem.compose]
383-
384- people = [
385- "aanand"
386- ]
387-
388- [Org.Subsystem.builder]
389-
390- people = [
391- "duglin",
392- "erikh",
393- "tibor"
394- ]
238+ [Org."Docs maintainers"]
239+
240+ # TODO Describe the docs maintainers role.
241+
242+ people = [
243+ "james",
244+ "moxiegirl",
245+ "thajeztah",
246+ "jamtur01",
247+ "sven"
248+ ]
395249
396250 [Org.Curators]
397251
0 commit comments