github.com/telepresenceio/telepresence/v2@v2.20.0-pro.6.0.20240517030216-236ea954e789/GOVERNANCE-maintainer.md (about)

     1  # Telepresence Project Governance
     2  
     3  The goal of the Telepresence project is to accelerate the "developer inner loop" for cloud-native application
     4  development on Kubernetes.
     5  
     6  Telepresence achieves this by creating a dynamic network bridge between a local development environment (e.g., a laptop)
     7  and a remote Kubernetes cluster.
     8  
     9  This governance explains how the project is run.
    10  
    11  - [Values](#values)
    12  - [Maintainers](#maintainers)
    13  - [Becoming a Maintainer](#becoming-a-maintainer)
    14  - [Meetings](#meetings)
    15  - [CNCF Resources](#cncf-resources)
    16  - [Code of Conduct Enforcement](#code-of-conduct)
    17  - [Security Response Team](#security-response-team)
    18  - [Voting](#voting)
    19  - [Modifications](#modifying-this-charter)
    20  
    21  ## Values
    22  
    23  The Telepresence project and its leadership embrace the following values:
    24  
    25  * Openness: Communication and decision-making happens in the open and is discoverable for future
    26    reference. As much as possible, all discussions and work take place in public
    27    forums and open repositories.
    28  
    29  * Fairness: All stakeholders have the opportunity to provide feedback and submit
    30    contributions, which will be considered on their merits.
    31  
    32  * Community over Product or Company: Sustaining and growing our community takes
    33    priority over shipping code or sponsors' organizational goals.  Each
    34    contributor participates in the project as an individual.
    35  
    36  * Inclusivity: We innovate through different perspectives and skill sets, which
    37    can only be accomplished in a welcoming and respectful environment.
    38  
    39  * Participation: Responsibilities within the project are earned through
    40    participation, and there is a clear path up the contributor ladder into leadership
    41    positions.
    42  
    43  ## Maintainers
    44  
    45  Telepresence Maintainers have write access to the [project GitHub repository](https://github.com/telepresenceio/telepresence).
    46  They can merge their own patches or patches from others. The current maintainers
    47  can be found in [MAINTAINERS.md](./MAINTAINERS.md).  Maintainers collectively manage the project's
    48  resources and contributors.
    49  
    50  This privilege is granted with some expectation of responsibility: maintainers
    51  are people who care about the Telepresence project and want to help it grow and
    52  improve. A maintainer is not just someone who can make changes, but someone who
    53  has demonstrated their ability to collaborate with the team, get the most
    54  knowledgeable people to review code and docs, contribute high-quality code, and
    55  follow through to fix issues (in code or tests).
    56  
    57  A maintainer is a contributor to the project's success and a citizen helping
    58  the project succeed.
    59  
    60  The collective team of all Maintainers is known as the Maintainer Council, which
    61  is the governing body for the project.
    62  
    63  ### Maintainer responsibilities
    64  
    65  * Monitor email aliases.
    66  * Monitor Slack (delayed response is perfectly acceptable).
    67  * Triage GitHub issues and perform pull request reviews for other maintainers and the community.
    68  * Make sure that ongoing PRs are moving forward at the right pace or closing them.
    69  * In general continue to be willing to spend at least 20% of one's time working on Telepresence (~1 business day/week).
    70  
    71  ### Becoming a Maintainer
    72  
    73  * Express interest to the current maintainers (see [MAINTAINERS.md](MAINTAINERS.md)) that your organization is
    74  interested in becoming a maintainer. Becoming a maintainer generally means that you are going to be spending
    75  substantial time on Telepresence for the foreseeable future.
    76  * We will expect you to start contributing increasingly complicated PRs, under the guidance of the existing maintainers.
    77  * We may ask you to do some PRs from our backlog.
    78  * As you gain experience with the code base and our standards, we will ask you to do code reviews for incoming PRs.
    79  All maintainers are expected to shoulder a proportional share of community reviews.
    80  * After a period of approximately 2-3 months of working together and making sure we see eye to eye, the existing
    81  maintainers will confer and decide whether to grant maintainer status or not.
    82  We make no guarantees on the length of time this will take, but 2-3 months is the goal.
    83  
    84  A new Maintainer can apply by sending a message in our [OSS Slack workspace](https://communityinviter.com/apps/cloud-native/cncf),
    85  in the [#telepresence-oss](https://cloud-native.slack.com/archives/C06B36KJ85P) channel.
    86  
    87  A simple majority vote of existing Maintainers approves the application.
    88  
    89  Maintainers nominations will be evaluated without prejudice
    90  to employer or demographics.
    91  
    92  Maintainers who are selected will be granted the necessary GitHub rights.
    93  
    94  ### Removing a Maintainer
    95  
    96  Maintainers may resign at any time if they feel that they will not be able to
    97  continue fulfilling their project duties.
    98  
    99  Maintainers may also be removed after being inactive, failure to fulfill their
   100  Maintainer responsibilities, violating the Code of Conduct, or other reasons.
   101  Inactivity is defined as a period of very low or no activity in the project
   102  for a year or more, with no definite schedule to return to full Maintainer
   103  activity.
   104  
   105  A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
   106  
   107  Depending on the reason for removal, a Maintainer may be converted to Emeritus
   108  status. Emeritus Maintainers will still be consulted on some project matters,
   109  and can be rapidly returned to Maintainer status if their availability changes.
   110  
   111  ## Meetings
   112  
   113  Time zones permitting, Maintainers are expected to participate in the public
   114  developer meeting.
   115  
   116  Details can be found [here](./MEETING_SCHEDULE.md#monthly-contributors-meeting).
   117  
   118  Maintainers will also have closed meetings in order to discuss security reports
   119  or Code of Conduct violations.  Such meetings should be scheduled by any
   120  Maintainer on receipt of a security issue or CoC report.  All current Maintainers
   121  must be invited to such closed meetings, except for any Maintainer who is
   122  accused of a CoC violation.
   123  
   124  ## CNCF Resources
   125  
   126  Any Maintainer may suggest a request for CNCF resources, either in the
   127  [#telepresence-dev](https://datawire-oss.slack.com/archives/CC5D1UTTN) in slack, or during a
   128  meeting.  A simple majority of Maintainers approves the request.  The Maintainers
   129  may also choose to delegate working with the CNCF to non-Maintainer community
   130  members, who will then be added to the [CNCF's Maintainer List](https://github.com/cncf/foundation/blob/main/project-maintainers.csv)
   131  for that purpose.
   132  
   133  ## Code of Conduct
   134  
   135  [Code of Conduct](./code-of-conduct.md)
   136  violations by community members will be discussed and resolved
   137  on the [private slack channel](https://datawire-oss.slack.com/archives/C061Q45SU4F).  If a Maintainer is directly involved
   138  in the report, the Maintainers will instead designate two Maintainers to work
   139  with the CNCF Code of Conduct Committee in resolving it.
   140  
   141  ## Security Response Team
   142  
   143  The Maintainers will appoint a Security Response Team to handle security reports.
   144  This committee may simply consist of the Maintainer Council themselves.  If this
   145  responsibility is delegated, the Maintainers will appoint a team of at least two
   146  contributors to handle it.  The Maintainers will review who is assigned to this
   147  at least once a year.
   148  
   149  The Security Response Team is responsible for handling all reports of security
   150  holes and breaches according to the [security policy](./SECURITY.md).
   151  
   152  ## Voting
   153  
   154  In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons
   155  involved. If a dispute cannot be decided independently, the maintainers can be called in to decide an issue. If the
   156  maintainers themselves cannot decide an issue, the issue will be resolved by voting.
   157  The voting process is a simple majority in which each maintainer receives one vote.
   158  
   159  A vote can be taken on [#telepresence-dev](https://datawire-oss.slack.com/archives/CC5D1UTTN) or
   160  [#telepresence-dev-private](https://datawire-oss.slack.com/archives/C061Q45SU4F) for security or conduct matters.
   161  
   162  Any Maintainer may demand a vote be taken.
   163  
   164  Most votes require a simple majority of all Maintainers to succeed, except where
   165  otherwise noted.  Two-thirds majority votes mean at least two-thirds of all
   166  existing maintainers.
   167  
   168  ## Modifying this Charter
   169  
   170  Changes to this Governance and its supporting documents may be approved by
   171  a 2/3 vote of the Maintainers.
   172  
   173  ## Adding new projects to the Telepresence GitHub organization
   174  
   175  New projects will be added to the Telepresence organization via GitHub issue discussion in one of the existing projects
   176  in the organization. Once sufficient discussion has taken place (~3-5 business days but depending on the volume
   177  of conversation), the maintainers of *the project where the issue was opened* (since different projects in the
   178  organization may have different maintainers) will decide whether the new project should be added. See the section
   179  above on voting if the maintainers cannot easily decide.