github.com/baris/docker@v1.7.0/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 * A pull request can be in 1 of 5 distinct states, for each of which there is a corresponding label 129 that needs to be applied. `Rules.review.states` contains the list of states with possible targets 130 for each. 131 """ 132 133 # Triage 134 [Rules.review.states.0-needs-triage] 135 136 # Maintainers are expected to triage new incoming pull requests by removing 137 # the `0-triage` label and adding the correct labels (e.g. `1-design-review`) 138 # potentially skipping some steps depending on the kind of pull request. 139 # Use common sense for judging. 140 # 141 # Checking for DCO should be done at this stage. 142 # 143 # If an owner, responsible for closing or merging, can be assigned to the PR, 144 # the better. 145 146 close = "e.g. unresponsive contributor without DCO" 147 3-docs-review = "non-proposal documentation-only change" 148 2-code-review = "e.g. trivial bugfix" 149 1-design-review = "general case" 150 151 # Design review 152 [Rules.review.states.1-needs-design-review] 153 154 # Maintainers are expected to comment on the design of the pull request. 155 # Review of documentation is expected only in the context of design validation, 156 # not for stylistic changes. 157 # 158 # Ideally, documentation should reflect the expected behavior of the code. 159 # No code review should take place in this step. 160 # 161 # Once design is approved, a maintainer should make sure to remove this label 162 # and add the next one. 163 164 close = "design rejected" 165 3-docs-review = "proposals with only documentation changes" 166 2-code-review = "general case" 167 168 # Code review 169 [Rules.review.states.2-needs-code-review] 170 171 # Maintainers are expected to review the code and ensure that it is good 172 # quality and in accordance with the documentation in the PR. 173 # 174 # If documentation is absent but expected, maintainers should ask for documentation. 175 # 176 # All tests should pass. 177 # 178 # Once code is approved according to the rules of the subsystem, a maintainer 179 # should make sure to remove this label and add the next one. 180 181 close = "" 182 1-design-review = "raises design concerns" 183 4-merge = "trivial change not impacting documentation" 184 3-docs-review = "general case" 185 186 # Docs review 187 [Rules.review.states.3-needs-docs-review] 188 189 # Maintainers are expected to review the documentation in its bigger context, 190 # ensuring consistency, completeness, validity, and breadth of coverage across 191 # all extent and new documentation. 192 # 193 # They should ask for any editorial change that makes the documentation more 194 # consistent and easier to understand. 195 # 196 # Changes and additions to docs must be reviewed and approved (LGTM'd) by a minimum of 197 # two docs sub-project maintainers. If the docs change originates with a docs 198 # maintainer, only one additional LGTM is required (since we assume a docs maintainer 199 # approves of their own PR). 200 # 201 # Once documentation is approved (see below), a maintainer should make sure to remove this 202 # label and add the next one. 203 204 close = "" 205 2-code-review = "requires more code changes" 206 1-design-review = "raises design concerns" 207 4-merge = "general case" 208 209 # Merge 210 [Rules.review.states.4-needs-merge] 211 212 # Maintainers are expected to merge this pull request as soon as possible. 213 # They can ask for a rebase, or carry the pull request themselves. 214 # These should be the easy PRs to merge. 215 216 close = "carry PR" 217 merge = "" 218 219 [Rules.DCO] 220 221 title = "Helping contributors with the DCO" 222 223 text = """ 224 The [DCO or `Sign your work`]( 225 https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work) 226 requirement is not intended as a roadblock or speed bump. 227 228 Some Docker contributors are not as familiar with `git`, or have used a web based 229 editor, and thus asking them to `git commit --amend -s` is not the best way forward. 230 231 In this case, maintainers can update the commits based on clause (c) of the DCO. The 232 most trivial way for a contributor to allow the maintainer to do this, is to add 233 a DCO signature in a Pull Requests's comment, or a maintainer can simply note that 234 the change is sufficiently trivial that it does not substantivly change the existing 235 contribution - i.e., a spelling change. 236 237 When you add someone's DCO, please also add your own to keep a log. 238 """ 239 240 [Rules.holiday] 241 242 title = "I'm a maintainer, and I'm going on holiday" 243 244 text = """ 245 Please let your co-maintainers and other contributors know by raising a pull 246 request that comments out your `MAINTAINERS` file entry using a `#`. 247 """ 248 249 [Rules."no direct push"] 250 251 title = "I'm a maintainer. Should I make pull requests too?" 252 253 text = """ 254 Yes. Nobody should ever push to master directly. All changes should be 255 made through a pull request. 256 """ 257 258 [Rules.meta] 259 260 title = "How is this process changed?" 261 262 text = "Just like everything else: by making a pull request :)" 263 264 # Current project organization 265 [Org] 266 267 bdfl = "shykes" 268 269 # The chief architect is responsible for the overall integrity of the technical architecture 270 # across all subsystems, and the consistency of APIs and UI. 271 # 272 # Changes to UI, public APIs and overall architecture (for example a plugin system) must 273 # be approved by the chief architect. 274 "Chief Architect" = "shykes" 275 276 # The Chief Operator is responsible for the day-to-day operations of the project including: 277 # - facilitating communications amongst all the contributors; 278 # - tracking release schedules; 279 # - managing the relationship with downstream distributions and upstream dependencies; 280 # - helping new contributors to get involved and become successful contributors and maintainers 281 # 282 # The role is also responsible for managing and measuring the success of the overall project 283 # and ensuring it is governed properly working in concert with the Docker Governance Advisory Board (DGAB). 284 "Chief Operator" = "spf13" 285 286 [Org.Operators] 287 288 # The operators make sure the trains run on time. They are responsible for overall operations 289 # of the project. This includes facilitating communication between all the participants; helping 290 # newcomers get involved and become successful contributors and maintainers; tracking the schedule 291 # of releases; managing the relationship with downstream distributions and upstream dependencies; 292 # define measures of success for the project and measure progress; Devise and implement tools and 293 # processes which make contributors and maintainers happier and more efficient. 294 295 296 [Org.Operators.security] 297 298 people = [ 299 "erw", 300 "diogomonica", 301 "nathanmccauley" 302 ] 303 304 [Org.Operators."monthly meetings"] 305 306 people = [ 307 "sven", 308 "tianon" 309 ] 310 311 [Org.Operators.infrastructure] 312 313 people = [ 314 "jfrazelle", 315 "crosbymichael" 316 ] 317 318 [Org.Operators.community] 319 people = [ 320 "theadactyl" 321 ] 322 323 # The chief maintainer is responsible for all aspects of quality for the project including 324 # code reviews, usability, stability, security, performance, etc. 325 # The most important function of the chief maintainer is to lead by example. On the first 326 # day of a new maintainer, the best advice should be "follow the C.M.'s example and you'll 327 # be fine". 328 "Chief Maintainer" = "crosbymichael" 329 330 # The community manager is responsible for serving the project community, including users, 331 # contributors and partners. This involves: 332 # - facilitating communication between maintainers, contributors and users 333 # - organizing contributor and maintainer events 334 # - helping new contributors get involved 335 # - anything the project community needs to be successful 336 # 337 # The community manager is a point of contact for any contributor who has questions, concerns 338 # or feedback about project operations. 339 "Community Manager" = "theadactyl" 340 341 [Org."Core maintainers"] 342 343 # The Core maintainers are the ghostbusters of the project: when there's a problem others 344 # can't solve, they show up and fix it with bizarre devices and weaponry. 345 # They have final say on technical implementation and coding style. 346 # They are ultimately responsible for quality in all its forms: usability polish, 347 # bugfixes, performance, stability, etc. When ownership can cleanly be passed to 348 # a subsystem, they are responsible for doing so and holding the 349 # subsystem maintainers accountable. If ownership is unclear, they are the de facto owners. 350 351 # For each release (including minor releases), a "release captain" is assigned from the 352 # pool of core maintainers. Rotation is encouraged across all maintainers, to ensure 353 # the release process is clear and up-to-date. 354 # 355 # It is common for core maintainers to "branch out" to join or start a subsystem. 356 357 358 359 people = [ 360 "crosbymichael", 361 "erikh", 362 "estesp", 363 "icecrime", 364 "jfrazelle", 365 "lk4d4", 366 "runcom", 367 "tibor", 368 "unclejack", 369 "vbatts", 370 "vieux", 371 "vishh" 372 ] 373 374 375 [Org.Subsystems] 376 377 # As the project grows, it gets separated into well-defined subsystems. Each subsystem 378 # has a dedicated group of maintainers, which are dedicated to that subsytem and responsible 379 # for its quality. 380 # This "cellular division" is the primary mechanism for scaling maintenance of the project as it grows. 381 # 382 # The maintainers of each subsytem are responsible for: 383 # 384 # 1. Exposing a clear road map for improving their subsystem. 385 # 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem. 386 # 3. Be available to anyone with questions, bug reports, criticism etc. 387 # on their component. This includes IRC, GitHub requests and the mailing 388 # list. 389 # 4. Make sure their subsystem respects the philosophy, design and 390 # road map of the project. 391 # 392 # #### How to review patches to your subsystem 393 # 394 # Accepting pull requests: 395 # 396 # - If the pull request appears to be ready to merge, give it a `LGTM`, which 397 # stands for "Looks Good To Me". 398 # - If the pull request has some small problems that need to be changed, make 399 # a comment adressing the issues. 400 # - If the changes needed to a PR are small, you can add a "LGTM once the 401 # following comments are adressed..." this will reduce needless back and 402 # forth. 403 # - If the PR only needs a few changes before being merged, any MAINTAINER can 404 # make a replacement PR that incorporates the existing commits and fixes the 405 # problems before a fast track merge. 406 # 407 # Closing pull requests: 408 # 409 # - If a PR appears to be abandoned, after having attempted to contact the 410 # original contributor, then a replacement PR may be made. Once the 411 # replacement PR is made, any contributor may close the original one. 412 # - If you are not sure if the pull request implements a good feature or you 413 # do not understand the purpose of the PR, ask the contributor to provide 414 # more documentation. If the contributor is not able to adequately explain 415 # the purpose of the PR, the PR may be closed by any MAINTAINER. 416 # - If a MAINTAINER feels that the pull request is sufficiently architecturally 417 # flawed, or if the pull request needs significantly more design discussion 418 # before being considered, the MAINTAINER should close the pull request with 419 # a short explanation of what discussion still needs to be had. It is 420 # important not to leave such pull requests open, as this will waste both the 421 # MAINTAINER's time and the contributor's time. It is not good to string a 422 # contributor on for weeks or months, having them make many changes to a PR 423 # that will eventually be rejected. 424 425 [Org.Subsystems.Documentation] 426 427 people = [ 428 "fredlf", 429 "james", 430 "moxiegirl", 431 "thaJeztah", 432 "jamtur01", 433 "spf13", 434 "sven" 435 ] 436 437 [Org.Subsystems.libcontainer] 438 439 people = [ 440 "crosbymichael", 441 "jnagal", 442 "lk4d4", 443 "mpatel", 444 "vmarmol" 445 ] 446 447 [Org.Subsystems.registry] 448 449 people = [ 450 "dmcg", 451 "dmp42", 452 "jlhawn", 453 "samalba", 454 "sday", 455 "vbatts" 456 ] 457 458 [Org.Subsystems."build tools"] 459 460 people = [ 461 "shykes", 462 "tianon" 463 ] 464 465 [Org.Subsystem."remote api"] 466 467 people = [ 468 "vieux" 469 ] 470 471 [Org.Subsystem.swarm] 472 473 people = [ 474 "aluzzardi", 475 "vieux" 476 ] 477 478 [Org.Subsystem.machine] 479 480 people = [ 481 "bfirsh", 482 "ehazlett" 483 ] 484 485 [Org.Subsystem.compose] 486 487 people = [ 488 "aanand" 489 ] 490 491 [Org.Subsystem.builder] 492 493 people = [ 494 "duglin", 495 "erikh", 496 "tibor" 497 ] 498 499 [Org.Curators] 500 501 # The curators help ensure that incoming issues and pull requests are properly triaged and 502 # that our various contribution and reviewing processes are respected. With their knowledge of 503 # the repository activity, they can also guide contributors to relevant material or 504 # discussions. 505 # 506 # They are neither code nor docs reviewers, so they are never expected to merge. They can 507 # however: 508 # - close an issue or pull request when it's an exact duplicate 509 # - close an issue or pull request when it's inappropriate or off-topic 510 511 people = [ 512 "thajeztah" 513 ] 514 515 516 [people] 517 518 # A reference list of all people associated with the project. 519 # All other sections should refer to people by their canonical key 520 # in the people section. 521 522 # ADD YOURSELF HERE IN ALPHABETICAL ORDER 523 524 [people.aanand] 525 Name = "Aanand Prasad" 526 Email = "aanand@docker.com" 527 GitHub = "aanand" 528 529 [people.aluzzardi] 530 Name = "Andrea Luzzardi" 531 Email = "aluzzardi@docker.com" 532 GitHub = "aluzzardi" 533 534 [people.bfirsh] 535 Name = "Ben Firshman" 536 Email = "ben@firshman.co.uk" 537 GitHub = "bfirsh" 538 539 [people.cpuguy83] 540 Name = "Brian Goff" 541 Email = "cpuguy83@gmail.com" 542 Github = "cpuguy83" 543 544 [people.crosbymichael] 545 Name = "Michael Crosby" 546 Email = "crosbymichael@gmail.com" 547 GitHub = "crosbymichael" 548 549 [people.diogomonica] 550 Name = "Diogo Monica" 551 Email = "diogo@docker.com" 552 GitHub = "diogomonica" 553 554 [people.duglin] 555 Name = "Doug Davis" 556 Email = "dug@us.ibm.com" 557 GitHub = "duglin" 558 559 [people.dmcg] 560 Name = "Derek McGowan" 561 Email = "derek@docker.com" 562 Github = "dmcgowan" 563 564 [people.dmp42] 565 Name = "Olivier Gambier" 566 Email = "olivier@docker.com" 567 Github = "dmp42" 568 569 [people.ehazlett] 570 Name = "Evan Hazlett" 571 Email = "ejhazlett@gmail.com" 572 GitHub = "ehazlett" 573 574 [people.erikh] 575 Name = "Erik Hollensbe" 576 Email = "erik@docker.com" 577 GitHub = "erikh" 578 579 [people.erw] 580 Name = "Eric Windisch" 581 Email = "eric@windisch.us" 582 GitHub = "ewindisch" 583 584 [people.estesp] 585 Name = "Phil Estes" 586 Email = "estesp@linux.vnet.ibm.com" 587 GitHub = "estesp" 588 589 [people.fredlf] 590 Name = "Fred Lifton" 591 Email = "fred.lifton@docker.com" 592 GitHub = "fredlf" 593 594 [people.icecrime] 595 Name = "Arnaud Porterie" 596 Email = "arnaud@docker.com" 597 GitHub = "icecrime" 598 599 [people.jfrazelle] 600 Name = "Jessie Frazelle" 601 Email = "j@docker.com" 602 GitHub = "jfrazelle" 603 604 [people.jlhawn] 605 Name = "Josh Hawn" 606 Email = "josh.hawn@docker.com" 607 Github = "jlhawn" 608 609 [people.lk4d4] 610 Name = "Alexander Morozov" 611 Email = "lk4d4@docker.com" 612 GitHub = "lk4d4" 613 614 [people.moxiegirl] 615 Name = "Mary Anthony" 616 Email = "mary.anthony@docker.com" 617 GitHub = "moxiegirl" 618 619 [people.nathanmccauley] 620 Name = "Nathan McCauley" 621 Email = "nathan.mccauley@docker.com" 622 GitHub = "nathanmccauley" 623 624 [people.runcom] 625 Name = "Antonio Murdaca" 626 Email = "me@runcom.ninja" 627 GitHub = "runcom" 628 629 [people.sday] 630 Name = "Stephen Day" 631 Email = "stephen.day@docker.com" 632 Github = "stevvooe" 633 634 [people.shykes] 635 Name = "Solomon Hykes" 636 Email = "solomon@docker.com" 637 GitHub = "shykes" 638 639 [people.spf13] 640 Name = "Steve Francia" 641 Email = "steve.francia@gmail.com" 642 GitHub = "spf13" 643 644 [people.sven] 645 Name = "Sven Dowideit" 646 Email = "SvenDowideit@home.org.au" 647 GitHub = "SvenDowideit" 648 649 [people.thajeztah] 650 Name = "Sebastiaan van Stijn" 651 Email = "github@gone.nl" 652 GitHub = "thaJeztah" 653 654 [people.theadactyl] 655 Name = "Thea Lamkin" 656 Email = "thea@docker.com" 657 GitHub = "theadactyl" 658 659 [people.tianon] 660 Name = "Tianon Gravi" 661 Email = "admwiggin@gmail.com" 662 GitHub = "tianon" 663 664 [people.tibor] 665 Name = "Tibor Vass" 666 Email = "tibor@docker.com" 667 GitHub = "tiborvass" 668 669 [people.vbatts] 670 Name = "Vincent Batts" 671 Email = "vbatts@redhat.com" 672 GitHub = "vbatts" 673 674 [people.vieux] 675 Name = "Victor Vieux" 676 Email = "vieux@docker.com" 677 GitHub = "vieux" 678 679 [people.vmarmol] 680 Name = "Victor Marmol" 681 Email = "vmarmol@google.com" 682 GitHub = "vmarmol" 683 684 [people.jnagal] 685 Name = "Rohit Jnagal" 686 Email = "jnagal@google.com" 687 GitHub = "rjnagal" 688 689 [people.mpatel] 690 Name = "Mrunal Patel" 691 Email = "mpatel@redhat.com" 692 GitHub = "mrunalp" 693 694 [people.unclejack] 695 Name = "Cristian Staretu" 696 Email = "cristian.staretu@gmail.com" 697 GitHub = "unclejack" 698 699 [people.vishh] 700 Name = "Vishnu Kannan" 701 Email = "vishnuk@google.com" 702 GitHub = "vishh"