github.com/demonoid81/moby@v0.0.0-20200517203328-62dd8e17c460/project/GOVERNANCE.md (about)

     1  # Moby project governance
     2  
     3  Moby projects are governed by the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc).
     4  See the Moby TSC [charter](https://github.com/moby/tsc/blob/master/README.md) for
     5  further information on the role of the TSC and procedures for escalation
     6  of technical issues or concerns.
     7  
     8  Contact [any Moby TSC member](https://github.com/moby/tsc/blob/master/MEMBERS.md) with your questions/concerns about the governance or a specific technical 
     9  issue that you feel requires escalation.
    10  
    11  ## Project maintainers
    12  
    13  The current maintainers of the moby/moby repository are listed in the
    14  [MAINTAINERS](/MAINTAINERS) file.
    15  
    16  There are different types of maintainers, with different responsibilities, but
    17  all maintainers have 3 things in common:
    18  
    19   1. They share responsibility in the project's success.
    20   2. They have made a long-term, recurring time investment to improve the project.
    21   3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun.
    22  
    23  Maintainers are often under-appreciated, because their work is less visible.
    24  It's easy to recognize a really cool and technically advanced feature. It's harder
    25  to appreciate the absence of bugs, the slow but steady improvement in stability,
    26  or the reliability of a release process. But those things distinguish a good
    27  project from a great one.
    28  
    29  ### Adding maintainers
    30  
    31  Maintainers are first and foremost contributors who have shown their
    32  commitment to the long term success of a project. Contributors who want to
    33  become maintainers first demonstrate commitment to the project by contributing
    34  code, reviewing others' work, and triaging issues on a regular basis for at
    35  least three months.
    36  
    37  The contributions alone don't make you a maintainer. You need to earn the
    38  trust of the current maintainers and other project contributors, that your
    39  decisions and actions are in the best interest of the project.
    40  
    41  Periodically, the existing maintainers curate a list of contributors who have
    42  shown regular activity on the project over the prior months. From this
    43  list, maintainer candidates are selected and proposed on the maintainers
    44  mailing list.
    45  
    46  After a candidate is announced on the maintainers mailing list, the
    47  existing maintainers discuss the candidate over the next 5 business days,
    48  provide feedback, and vote. At least 66% of the current maintainers must
    49  vote in the affirmative.
    50  
    51  If a candidate is approved, a maintainer contacts the candidate to
    52  invite them to open a pull request that adds the contributor to
    53  the MAINTAINERS file. The candidate becomes a maintainer once the pull
    54  request is merged.
    55  
    56  ### Removing maintainers
    57  
    58  Maintainers can be removed from the project, either at their own request
    59  or due to [project inactivity](#inactive-maintainer-policy).
    60  
    61  #### How to step down
    62  
    63  Life priorities, interests, and passions can change. If you're a maintainer but
    64  feel you must remove yourself from the list, inform other maintainers that you
    65  intend to step down, and if possible, help find someone to pick up your work.
    66  At the very least, ensure your work can be continued where you left off.
    67  
    68  After you've informed other maintainers, create a pull request to remove
    69  yourself from the MAINTAINERS file.
    70  
    71  #### Inactive maintainer policy
    72  
    73  An existing maintainer can be removed if they do not show significant activity
    74  on the project. Periodically, the maintainers review the list of maintainers
    75  and their activity over the last three months.
    76  
    77  If a maintainer has shown insufficient activity over this period, a project
    78  representative will contact the maintainer to ask if they want to continue
    79  being a maintainer. If the maintainer decides to step down as a maintainer,
    80  they open a pull request to be removed from the MAINTAINERS file.
    81  
    82  If the maintainer wants to continue in this role, but is unable to perform the
    83  required duties, they can be removed with a vote by at least 66% of the current
    84  maintainers. The maintainer under discussion will not be allowed to vote. An
    85  e-mail is sent to the mailing list, inviting maintainers of the project to
    86  vote. The voting period is five business days. Issues related to a maintainer's
    87  performance should be discussed with them among the other maintainers so that
    88  they are not surprised by a pull request removing them. This discussion should
    89  be handled objectively with no ad hominem attacks.
    90  
    91  ## Project decision making
    92  
    93  Short answer: **Everything is a pull request**.
    94  
    95  The Moby core engine project is an open-source project with an open design
    96  philosophy. This means that the repository is the source of truth for **every**
    97  aspect of the project, including its philosophy, design, road map, and APIs.
    98  *If it's part of the project, it's in the repo. If it's in the repo, it's part
    99  of the project.*
   100  
   101  As a result, each decision can be expressed as a change to the repository. An
   102  implementation change is expressed as a change to the source code. An API
   103  change is a change to the API specification. A philosophy change is a change
   104  to the philosophy manifesto, and so on.
   105  
   106  All decisions affecting the moby/moby repository, both big and small, follow
   107  the same steps:
   108  
   109   * **Step 1**: Open a pull request. Anyone can do this.
   110  
   111   * **Step 2**: Discuss the pull request. Anyone can do this.
   112  
   113   * **Step 3**: Maintainers merge, close or reject the pull request.
   114  
   115  Pull requests are reviewed by the current maintainers of the moby/moby
   116  repository. Weekly meetings are organized to are organized to synchronously
   117  discuss tricky PRs, as well as design and architecture decisions.. When
   118  technical agreement cannot be reached among the maintainers of the project,
   119  escalation or concerns can be raised by opening an issue to be handled
   120  by the [Moby Technical Steering Committee](https://github.com/moby/tsc).