github.com/crquan/docker@v1.8.1/MAINTAINERS (about) 1 # Docker maintainers file 2 # 3 # This file describes who runs the Docker project and how. 4 # This is a living document - if you see something out of date or missing, 5 # speak up! 6 # 7 # It is structured to be consumable by both humans and programs. 8 # To extract its contents programmatically, use any TOML-compliant 9 # parser. 10 11 [Rules] 12 13 [Rules.maintainers] 14 15 title = "What is a maintainer?" 16 17 text = """ 18 There are different types of maintainers, with different responsibilities, but 19 all maintainers have 3 things in common: 20 21 1) They share responsibility in the project's success. 22 2) They have made a long-term, recurring time investment to improve the project. 23 3) They spend that time doing whatever needs to be done, not necessarily what 24 is the most interesting or fun. 25 26 Maintainers are often under-appreciated, because their work is harder to appreciate. 27 It's easy to appreciate a really cool and technically advanced feature. It's harder 28 to appreciate the absence of bugs, the slow but steady improvement in stability, 29 or the reliability of a release process. But those things distinguish a good 30 project from a great one. 31 """ 32 33 [Rules.bdfl] 34 35 title = "The Benevolent dictator for life (BDFL)" 36 37 text = """ 38 Docker follows the timeless, highly efficient and totally unfair system 39 known as [Benevolent dictator for 40 life](https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with 41 yours truly, Solomon Hykes, in the role of BDFL. This means that all 42 decisions are made, by default, by Solomon. Since making every decision 43 myself would be highly un-scalable, in practice decisions are spread 44 across multiple maintainers. 45 46 Ideally, the BDFL role is like the Queen of England: awesome crown, but not 47 an actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY. 48 Every other rule can change, perhaps drastically so, but the BDFL will always 49 be there, preserving the philosophy and principles of the project, and keeping 50 ultimate authority over its fate. This gives us great flexibility in experimenting 51 with various governance models, knowing that we can always press the "reset" button 52 without fear of fragmentation or deadlock. See the US congress for a counter-example. 53 54 BDFL daily routine: 55 56 * Is the project governance stuck in a deadlock or irreversibly fragmented? 57 * If yes: refactor the project governance 58 * Are there issues or conflicts escalated by core? 59 * If yes: resolve them 60 * Go back to polishing that crown. 61 """ 62 63 [Rules.decisions] 64 65 title = "How are decisions made?" 66 67 text = """ 68 Short answer: EVERYTHING IS A PULL REQUEST. 69 70 Docker is an open-source project with an open design philosophy. This 71 means that the repository is the source of truth for EVERY aspect of the 72 project, including its philosophy, design, road map, and APIs. *If it's 73 part of the project, it's in the repo. If it's in the repo, it's part of 74 the project.* 75 76 As a result, all decisions can be expressed as changes to the 77 repository. An implementation change is a change to the source code. An 78 API change is a change to the API specification. A philosophy change is 79 a change to the philosophy manifesto, and so on. 80 81 All decisions affecting Docker, big and small, follow the same 3 steps: 82 83 * Step 1: Open a pull request. Anyone can do this. 84 85 * Step 2: Discuss the pull request. Anyone can do this. 86 87 * Step 3: Merge or refuse the pull request. Who does this depends on the nature 88 of the pull request and which areas of the project it affects. See *review flow* 89 for details. 90 91 Because Docker is such a large and active project, it's important for everyone to know 92 who is responsible for deciding what. That is determined by a precise set of rules. 93 94 * For every *decision* in the project, the rules should designate, in a deterministic way, 95 who should *decide*. 96 97 * For every *problem* in the project, the rules should designate, in a deterministic way, 98 who should be responsible for *fixing* it. 99 100 * For every *question* in the project, the rules should designate, in a deterministic way, 101 who should be expected to have the *answer*. 102 """ 103 104 [Rules.review] 105 106 title = "Review flow" 107 108 text = """ 109 Pull requests should be processed according to the following flow: 110 111 * For each subsystem affected by the change, the maintainers of the subsystem must approve or refuse it. 112 It is the responsibility of the subsystem maintainers to process patches affecting them in a timely 113 manner. 114 115 * If the change affects areas of the code which are not part of a subsystem, 116 or if subsystem maintainers are unable to reach a timely decision, it must be approved by 117 the core maintainers. 118 119 * If the change affects the UI or public APIs, or if it represents a major change in architecture, 120 the architects must approve or refuse it. 121 122 * If the change affects the operations of the project, it must be approved or rejected by 123 the relevant operators. 124 125 * If the change affects the governance, philosophy, goals or principles of the project, 126 it must be approved by BDFL. 127 """ 128 129 [Rules.DCO] 130 131 title = "Helping contributors with the DCO" 132 133 text = """ 134 The [DCO or `Sign your work`]( 135 https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work) 136 requirement is not intended as a roadblock or speed bump. 137 138 Some Docker contributors are not as familiar with `git`, or have used a web based 139 editor, and thus asking them to `git commit --amend -s` is not the best way forward. 140 141 In this case, maintainers can update the commits based on clause (c) of the DCO. The 142 most trivial way for a contributor to allow the maintainer to do this, is to add 143 a DCO signature in a Pull Requests's comment, or a maintainer can simply note that 144 the change is sufficiently trivial that it does not substantivly change the existing 145 contribution - i.e., a spelling change. 146 147 When you add someone's DCO, please also add your own to keep a log. 148 """ 149 150 [Rules.holiday] 151 152 title = "I'm a maintainer, and I'm going on holiday" 153 154 text = """ 155 Please let your co-maintainers and other contributors know by raising a pull 156 request that comments out your `MAINTAINERS` file entry using a `#`. 157 """ 158 159 [Rules."no direct push"] 160 161 title = "I'm a maintainer. Should I make pull requests too?" 162 163 text = """ 164 Yes. Nobody should ever push to master directly. All changes should be 165 made through a pull request. 166 """ 167 168 [Rules.meta] 169 170 title = "How is this process changed?" 171 172 text = "Just like everything else: by making a pull request :)" 173 174 # Current project organization 175 [Org] 176 177 bdfl = "shykes" 178 179 # The chief architect is responsible for the overall integrity of the technical architecture 180 # across all subsystems, and the consistency of APIs and UI. 181 # 182 # Changes to UI, public APIs and overall architecture (for example a plugin system) must 183 # be approved by the chief architect. 184 "Chief Architect" = "shykes" 185 186 # The Chief Operator is responsible for the day-to-day operations of the project including: 187 # - facilitating communications amongst all the contributors; 188 # - tracking release schedules; 189 # - managing the relationship with downstream distributions and upstream dependencies; 190 # - helping new contributors to get involved and become successful contributors and maintainers 191 # 192 # The role is also responsible for managing and measuring the success of the overall project 193 # and ensuring it is governed properly working in concert with the Docker Governance Advisory Board (DGAB). 194 "Chief Operator" = "spf13" 195 196 [Org.Operators] 197 198 # The operators make sure the trains run on time. They are responsible for overall operations 199 # of the project. This includes facilitating communication between all the participants; helping 200 # newcomers get involved and become successful contributors and maintainers; tracking the schedule 201 # of releases; managing the relationship with downstream distributions and upstream dependencies; 202 # define measures of success for the project and measure progress; Devise and implement tools and 203 # processes which make contributors and maintainers happier and more efficient. 204 205 206 [Org.Operators.security] 207 208 people = [ 209 "erw", 210 "diogomonica", 211 "nathanmccauley" 212 ] 213 214 [Org.Operators."monthly meetings"] 215 216 people = [ 217 "sven", 218 "tianon" 219 ] 220 221 [Org.Operators.infrastructure] 222 223 people = [ 224 "jfrazelle", 225 "crosbymichael" 226 ] 227 228 [Org.Operators.community] 229 people = [ 230 "theadactyl" 231 ] 232 233 # The chief maintainer is responsible for all aspects of quality for the project including 234 # code reviews, usability, stability, security, performance, etc. 235 # The most important function of the chief maintainer is to lead by example. On the first 236 # day of a new maintainer, the best advice should be "follow the C.M.'s example and you'll 237 # be fine". 238 "Chief Maintainer" = "crosbymichael" 239 240 # The community manager is responsible for serving the project community, including users, 241 # contributors and partners. This involves: 242 # - facilitating communication between maintainers, contributors and users 243 # - organizing contributor and maintainer events 244 # - helping new contributors get involved 245 # - anything the project community needs to be successful 246 # 247 # The community manager is a point of contact for any contributor who has questions, concerns 248 # or feedback about project operations. 249 "Community Manager" = "theadactyl" 250 251 [Org."Core maintainers"] 252 253 # The Core maintainers are the ghostbusters of the project: when there's a problem others 254 # can't solve, they show up and fix it with bizarre devices and weaponry. 255 # They have final say on technical implementation and coding style. 256 # They are ultimately responsible for quality in all its forms: usability polish, 257 # bugfixes, performance, stability, etc. When ownership can cleanly be passed to 258 # a subsystem, they are responsible for doing so and holding the 259 # subsystem maintainers accountable. If ownership is unclear, they are the de facto owners. 260 261 # For each release (including minor releases), a "release captain" is assigned from the 262 # pool of core maintainers. Rotation is encouraged across all maintainers, to ensure 263 # the release process is clear and up-to-date. 264 # 265 # It is common for core maintainers to "branch out" to join or start a subsystem. 266 267 268 269 people = [ 270 "calavera", 271 "crosbymichael", 272 "erikh", 273 "estesp", 274 "icecrime", 275 "jfrazelle", 276 "lk4d4", 277 "runcom", 278 "tibor", 279 "unclejack", 280 "vbatts", 281 "vieux", 282 "vishh" 283 ] 284 285 286 [Org.Subsystems] 287 288 # As the project grows, it gets separated into well-defined subsystems. Each subsystem 289 # has a dedicated group of maintainers, which are dedicated to that subsytem and responsible 290 # for its quality. 291 # This "cellular division" is the primary mechanism for scaling maintenance of the project as it grows. 292 # 293 # The maintainers of each subsytem are responsible for: 294 # 295 # 1. Exposing a clear road map for improving their subsystem. 296 # 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem. 297 # 3. Be available to anyone with questions, bug reports, criticism etc. 298 # on their component. This includes IRC, GitHub requests and the mailing 299 # list. 300 # 4. Make sure their subsystem respects the philosophy, design and 301 # road map of the project. 302 # 303 # #### How to review patches to your subsystem 304 # 305 # Accepting pull requests: 306 # 307 # - If the pull request appears to be ready to merge, give it a `LGTM`, which 308 # stands for "Looks Good To Me". 309 # - If the pull request has some small problems that need to be changed, make 310 # a comment adressing the issues. 311 # - If the changes needed to a PR are small, you can add a "LGTM once the 312 # following comments are adressed..." this will reduce needless back and 313 # forth. 314 # - If the PR only needs a few changes before being merged, any MAINTAINER can 315 # make a replacement PR that incorporates the existing commits and fixes the 316 # problems before a fast track merge. 317 # 318 # Closing pull requests: 319 # 320 # - If a PR appears to be abandoned, after having attempted to contact the 321 # original contributor, then a replacement PR may be made. Once the 322 # replacement PR is made, any contributor may close the original one. 323 # - If you are not sure if the pull request implements a good feature or you 324 # do not understand the purpose of the PR, ask the contributor to provide 325 # more documentation. If the contributor is not able to adequately explain 326 # the purpose of the PR, the PR may be closed by any MAINTAINER. 327 # - If a MAINTAINER feels that the pull request is sufficiently architecturally 328 # flawed, or if the pull request needs significantly more design discussion 329 # before being considered, the MAINTAINER should close the pull request with 330 # a short explanation of what discussion still needs to be had. It is 331 # important not to leave such pull requests open, as this will waste both the 332 # MAINTAINER's time and the contributor's time. It is not good to string a 333 # contributor on for weeks or months, having them make many changes to a PR 334 # that will eventually be rejected. 335 336 [Org.Subsystems.Documentation] 337 338 people = [ 339 "fredlf", 340 "james", 341 "moxiegirl", 342 "thaJeztah", 343 "jamtur01", 344 "spf13", 345 "sven" 346 ] 347 348 [Org.Subsystems.libcontainer] 349 350 people = [ 351 "crosbymichael", 352 "jnagal", 353 "lk4d4", 354 "mpatel", 355 "vmarmol" 356 ] 357 358 [Org.Subsystems.registry] 359 360 people = [ 361 "dmcg", 362 "dmp42", 363 "jlhawn", 364 "samalba", 365 "sday", 366 "vbatts" 367 ] 368 369 [Org.Subsystems."build tools"] 370 371 people = [ 372 "shykes", 373 "tianon" 374 ] 375 376 [Org.Subsystem."remote api"] 377 378 people = [ 379 "vieux" 380 ] 381 382 [Org.Subsystem.swarm] 383 384 people = [ 385 "aluzzardi", 386 "vieux" 387 ] 388 389 [Org.Subsystem.machine] 390 391 people = [ 392 "bfirsh", 393 "ehazlett" 394 ] 395 396 [Org.Subsystem.compose] 397 398 people = [ 399 "aanand" 400 ] 401 402 [Org.Subsystem.builder] 403 404 people = [ 405 "duglin", 406 "erikh", 407 "tibor" 408 ] 409 410 [Org.Curators] 411 412 # The curators help ensure that incoming issues and pull requests are properly triaged and 413 # that our various contribution and reviewing processes are respected. With their knowledge of 414 # the repository activity, they can also guide contributors to relevant material or 415 # discussions. 416 # 417 # They are neither code nor docs reviewers, so they are never expected to merge. They can 418 # however: 419 # - close an issue or pull request when it's an exact duplicate 420 # - close an issue or pull request when it's inappropriate or off-topic 421 422 people = [ 423 "thajeztah" 424 ] 425 426 427 [people] 428 429 # A reference list of all people associated with the project. 430 # All other sections should refer to people by their canonical key 431 # in the people section. 432 433 # ADD YOURSELF HERE IN ALPHABETICAL ORDER 434 435 [people.aanand] 436 Name = "Aanand Prasad" 437 Email = "aanand@docker.com" 438 GitHub = "aanand" 439 440 [people.aluzzardi] 441 Name = "Andrea Luzzardi" 442 Email = "aluzzardi@docker.com" 443 GitHub = "aluzzardi" 444 445 [people.bfirsh] 446 Name = "Ben Firshman" 447 Email = "ben@firshman.co.uk" 448 GitHub = "bfirsh" 449 450 [people.calavera] 451 Name = "David Calavera" 452 Email = "david.calavera@gmail.com" 453 GitHub = "calavera" 454 455 [people.cpuguy83] 456 Name = "Brian Goff" 457 Email = "cpuguy83@gmail.com" 458 Github = "cpuguy83" 459 460 [people.crosbymichael] 461 Name = "Michael Crosby" 462 Email = "crosbymichael@gmail.com" 463 GitHub = "crosbymichael" 464 465 [people.diogomonica] 466 Name = "Diogo Monica" 467 Email = "diogo@docker.com" 468 GitHub = "diogomonica" 469 470 [people.duglin] 471 Name = "Doug Davis" 472 Email = "dug@us.ibm.com" 473 GitHub = "duglin" 474 475 [people.dmcg] 476 Name = "Derek McGowan" 477 Email = "derek@docker.com" 478 Github = "dmcgowan" 479 480 [people.dmp42] 481 Name = "Olivier Gambier" 482 Email = "olivier@docker.com" 483 Github = "dmp42" 484 485 [people.ehazlett] 486 Name = "Evan Hazlett" 487 Email = "ejhazlett@gmail.com" 488 GitHub = "ehazlett" 489 490 [people.erikh] 491 Name = "Erik Hollensbe" 492 Email = "erik@docker.com" 493 GitHub = "erikh" 494 495 [people.erw] 496 Name = "Eric Windisch" 497 Email = "eric@windisch.us" 498 GitHub = "ewindisch" 499 500 [people.estesp] 501 Name = "Phil Estes" 502 Email = "estesp@linux.vnet.ibm.com" 503 GitHub = "estesp" 504 505 [people.fredlf] 506 Name = "Fred Lifton" 507 Email = "fred.lifton@docker.com" 508 GitHub = "fredlf" 509 510 [people.icecrime] 511 Name = "Arnaud Porterie" 512 Email = "arnaud@docker.com" 513 GitHub = "icecrime" 514 515 [people.jfrazelle] 516 Name = "Jessie Frazelle" 517 Email = "j@docker.com" 518 GitHub = "jfrazelle" 519 520 [people.jlhawn] 521 Name = "Josh Hawn" 522 Email = "josh.hawn@docker.com" 523 Github = "jlhawn" 524 525 [people.lk4d4] 526 Name = "Alexander Morozov" 527 Email = "lk4d4@docker.com" 528 GitHub = "lk4d4" 529 530 [people.moxiegirl] 531 Name = "Mary Anthony" 532 Email = "mary.anthony@docker.com" 533 GitHub = "moxiegirl" 534 535 [people.nathanmccauley] 536 Name = "Nathan McCauley" 537 Email = "nathan.mccauley@docker.com" 538 GitHub = "nathanmccauley" 539 540 [people.runcom] 541 Name = "Antonio Murdaca" 542 Email = "me@runcom.ninja" 543 GitHub = "runcom" 544 545 [people.sday] 546 Name = "Stephen Day" 547 Email = "stephen.day@docker.com" 548 Github = "stevvooe" 549 550 [people.shykes] 551 Name = "Solomon Hykes" 552 Email = "solomon@docker.com" 553 GitHub = "shykes" 554 555 [people.spf13] 556 Name = "Steve Francia" 557 Email = "steve.francia@gmail.com" 558 GitHub = "spf13" 559 560 [people.sven] 561 Name = "Sven Dowideit" 562 Email = "SvenDowideit@home.org.au" 563 GitHub = "SvenDowideit" 564 565 [people.thajeztah] 566 Name = "Sebastiaan van Stijn" 567 Email = "github@gone.nl" 568 GitHub = "thaJeztah" 569 570 [people.theadactyl] 571 Name = "Thea Lamkin" 572 Email = "thea@docker.com" 573 GitHub = "theadactyl" 574 575 [people.tianon] 576 Name = "Tianon Gravi" 577 Email = "admwiggin@gmail.com" 578 GitHub = "tianon" 579 580 [people.tibor] 581 Name = "Tibor Vass" 582 Email = "tibor@docker.com" 583 GitHub = "tiborvass" 584 585 [people.vbatts] 586 Name = "Vincent Batts" 587 Email = "vbatts@redhat.com" 588 GitHub = "vbatts" 589 590 [people.vieux] 591 Name = "Victor Vieux" 592 Email = "vieux@docker.com" 593 GitHub = "vieux" 594 595 [people.vmarmol] 596 Name = "Victor Marmol" 597 Email = "vmarmol@google.com" 598 GitHub = "vmarmol" 599 600 [people.jnagal] 601 Name = "Rohit Jnagal" 602 Email = "jnagal@google.com" 603 GitHub = "rjnagal" 604 605 [people.mpatel] 606 Name = "Mrunal Patel" 607 Email = "mpatel@redhat.com" 608 GitHub = "mrunalp" 609 610 [people.unclejack] 611 Name = "Cristian Staretu" 612 Email = "cristian.staretu@gmail.com" 613 GitHub = "unclejack" 614 615 [people.vishh] 616 Name = "Vishnu Kannan" 617 Email = "vishnuk@google.com" 618 GitHub = "vishh"