github.com/opencontainers/runtime-tools@v0.9.0/MAINTAINERS_GUIDE.md (about)

     1  ## Introduction
     2  
     3  Dear maintainer. Thank you for investing the time and energy to help
     4  make this project as useful as possible. Maintaining a project is difficult,
     5  sometimes unrewarding work.  Sure, you will get to contribute cool
     6  features to the project. But most of your time will be spent reviewing,
     7  cleaning up, documenting, answering questions, justifying design
     8  decisions - while everyone has all the fun! But remember - the quality
     9  of the maintainers work is what distinguishes the good projects from the
    10  great.  So please be proud of your work, even the unglamorous parts,
    11  and encourage a culture of appreciation and respect for *every* aspect
    12  of improving the project - not just the hot new features.
    13  
    14  This document is a manual for maintainers old and new. It explains what
    15  is expected of maintainers, how they should work, and what tools are
    16  available to them.
    17  
    18  This is a living document - if you see something out of date or missing,
    19  speak up!
    20  
    21  ## What are a maintainer's responsibility?
    22  
    23  It is every maintainer's responsibility to:
    24  
    25  * 1) Expose a clear roadmap for improving their component.
    26  * 2) Deliver prompt feedback and decisions on pull requests.
    27  * 3) Be available to anyone with questions, bug reports, criticism etc.
    28    on their component. This includes IRC and GitHub issues and pull requests.
    29  * 4) Make sure their component respects the philosophy, design and
    30    roadmap of the project.
    31  
    32  ## How are decisions made?
    33  
    34  Short answer: with pull requests to the project repository.
    35  
    36  This project is an open-source project with an open design philosophy. This
    37  means that the repository is the source of truth for EVERY aspect of the
    38  project, including its philosophy, design, roadmap and APIs. *If it's
    39  part of the project, it's in the repo. It's in the repo, it's part of
    40  the project.*
    41  
    42  As a result, all decisions can be expressed as changes to the
    43  repository. An implementation change is a change to the source code. An
    44  API change is a change to the API specification. A philosophy change is
    45  a change to the philosophy manifesto. And so on.
    46  
    47  All decisions affecting this project, big and small, follow the same 3 steps:
    48  
    49  * Step 1: Open a pull request. Anyone can do this.
    50  
    51  * Step 2: Discuss the pull request. Anyone can do this.
    52  
    53  * Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do 
    54  this (see below "Who decides what?")
    55  
    56  ### I'm a maintainer, should I make pull requests too?
    57  
    58  Yes. Nobody should ever push to master directly. All changes should be
    59  made through a pull request.
    60  
    61  ## Who decides what?
    62  
    63  All decisions are pull requests, and the relevant maintainers make
    64  decisions by accepting or refusing the pull request. Review and acceptance
    65  by anyone is denoted by adding a comment in the pull request: `LGTM`.
    66  However, only currently listed `MAINTAINERS` are counted towards the required
    67  one LGTM.
    68  
    69  Overall the maintainer system works because of mutual respect across the
    70  maintainers of the project.  The maintainers trust one another to make decisions
    71  in the best interests of the project.  Sometimes maintainers can disagree and
    72  this is part of a healthy project to represent the point of views of various people.
    73  In the case where maintainers cannot find agreement on a specific change the
    74  role of a Chief Maintainer comes into play.
    75  
    76  The Chief Maintainer for the project is responsible for overall architecture
    77  of the project to maintain conceptual integrity.  Large decisions and
    78  architecture changes should be reviewed by the chief maintainer.
    79  The current chief maintainer for the project is the first person listed
    80  in the MAINTAINERS file.
    81  
    82  Even though the maintainer system is built on trust, if there is a conflict
    83  with the chief maintainer on a decision, their decision can be challenged
    84  and brought to the technical oversight board if two-thirds of the
    85  maintainers vote for an appeal. It is expected that this would be a
    86  very exceptional event.
    87  
    88  
    89  ### How are maintainers added?
    90  
    91  The best maintainers have a vested interest in the project.  Maintainers
    92  are first and foremost contributors that have shown they are committed to
    93  the long term success of the project.  Contributors wanting to become
    94  maintainers are expected to be deeply involved in contributing code,
    95  pull request review, and triage of issues in the project for more than two months.
    96  
    97  Just contributing does not make you a maintainer, it is about building trust
    98  with the current maintainers of the project and being a person that they can
    99  depend on and trust to make decisions in the best interest of the project.  The
   100  final vote to add a new maintainer should be approved by over 66% of the current
   101  maintainers with the chief maintainer having veto power.  In case of a veto,
   102  conflict resolution rules expressed above apply.  The voting period is
   103  five business days on the Pull Request to add the new maintainer.
   104  
   105  
   106  ### What is expected of maintainers?
   107  
   108  Part of a healthy project is to have active maintainers to support the community
   109  in contributions and perform tasks to keep the project running.  Maintainers are
   110  expected to be able to respond in a timely manner if their help is required on specific
   111  issues where they are pinged.  Being a maintainer is a time consuming commitment and should
   112  not be taken lightly.
   113  
   114  When a maintainer is unable to perform the required duties they can be removed with
   115  a vote by 66% of the current maintainers with the chief maintainer having veto power.
   116  The voting period is ten business days.  Issues related to a maintainer's performance should
   117  be discussed with them among the other maintainers so that they are not surprised by
   118  a pull request removing them.
   119  
   120  
   121