github.com/pyroscope-io/pyroscope@v0.37.3-0.20230725203016-5f6947968bd0/GOVERNANCE.md (about)

     1  ---
     2  title: Governance
     3  ---
     4  
     5  # Governance
     6  
     7  This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Pyroscope community. Common terminology used in this governance document are listed below:
     8  
     9  - **Team members**: Any members of the private [team mailing list][team].
    10  
    11  - **Maintainers**: Maintainers lead an individual project or parts thereof ([`MAINTAINERS.md`][maintainers]).
    12  
    13  - **Projects**: A single repository in the Grafana GitHub organization and listed below is referred to as a project:
    14  
    15    - Pyroscope
    16  
    17  - **The Pyroscope project**: The sum of all activities performed under this governance, concerning one or more repositories or the community.
    18  
    19  ## Values
    20  
    21  The Pyroscope developers and community are expected to follow the values defined in the [Code of Conduct][coc]. Furthermore, the Pyroscope community strives for kindness, giving feedback effectively, and building a welcoming environment. The Pyroscope developers generally decide by consensus and only resort to conflict resolution by a majority vote if consensus cannot be reached.
    22  
    23  ## Projects
    24  
    25  Each project must have a [`MAINTAINERS.md`][maintainers] file with at least one maintainer. Where a project has a release process, access and documentation should be such that more than one person can perform a release. Releases should be announced on the [announcemount][announce] and [users][users] mailing lists. Any new projects should be first proposed on the [team mailing list][team] following the voting procedures listed below.
    26  
    27  ## Decision making
    28  
    29  ### Team members
    30  
    31  Team member status may be given to those who have made ongoing contributions to the Pyroscope project for at least 3 months. This is usually in the form of code improvements and/or notable work on documentation, but organizing events or user support could also be taken into account.
    32  
    33  New members may be proposed by any existing member by email to the [team mailing list][team]. It is highly desirable to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal [supermajority vote](#supermajority-vote).
    34  
    35  If the new member proposal is accepted, the proposed team member should be contacted privately via email to confirm or deny their acceptance of team membership. This email will also be CC'd to the [team mailing list][team] for record-keeping purposes.
    36  
    37  If they choose to accept, the [onboarding](#onboarding) procedure is followed.
    38  
    39  Team members may retire at any time by emailing [the team][team].
    40  
    41  Team members can be removed by [supermajority vote](#supermajority-vote) on [the team mailing list][team].
    42  For this vote, the member in question is not eligible to vote and does not count towards the quorum.
    43  Any removal vote can cover only one single person.
    44  
    45  Upon death of a member, they leave the team automatically.
    46  
    47  In case a member leaves, the [offboarding](#offboarding) procedure is applied.
    48  
    49  The current team members are:
    50  
    51  - Andrej Ocenas — [@aocenas](https://github.com/aocenas) ([Grafana Labs](https://grafana.com/))
    52  - Anton Kolesnikov - [@kolesnikovae](https://github.com/kolesnikovae) ([Grafana Labs](https://grafana.com/))
    53  - Christian Simon — [@simonswine](https://github.com/simonswine) ([Grafana Labs](https://grafana.com/))
    54  - Cristian Greco — [@cristiangreco](https://github.com/cristiangreco) ([Grafana Labs](https://grafana.com/))
    55  - Cyril Tovena — [@cyriltovena](https://github.com/cyriltovena) ([Grafana Labs](https://grafana.com/))
    56  - Dmitry Filimonov - [@petethepig](https://github.com/petethepig) ([Grafana Labs](https://grafana.com/))
    57  - Joey Tawadrous — [@joey-grafana](https://github.com/joey-grafana) ([Grafana Labs](https://grafana.com/))
    58  - Ryan Perry - [@Rperry2174](https://github.com/Rperry2174) ([Grafana Labs](https://grafana.com/))
    59  
    60  ### Maintainers
    61  
    62  Maintainers lead one or more project(s) or parts thereof and serve as a point of conflict resolution amongst the contributors to this project. Ideally, maintainers are also team members, but exceptions are possible for suitable maintainers that, for whatever reason, are not yet team members.
    63  
    64  Changes in maintainership have to be announced on the [developers mailing list][devs]. They are decided by [rough consensus](#consensus) and formalized by changing the [`MAINTAINERS.md`][maintainers] file of the respective repository.
    65  
    66  Maintainers are granted commit rights to all projects covered by this governance.
    67  
    68  A maintainer or committer may resign by notifying the [team mailing list][team]. A maintainer with no project activity for a year is considered to have resigned. Maintainers that wish to resign are encouraged to propose another team member to take over the project.
    69  
    70  A project may have multiple maintainers, as long as the responsibilities are clearly agreed upon between them. This includes coordinating who handles which issues and pull requests.
    71  
    72  ### Technical decisions
    73  
    74  Technical decisions that only affect a single project are made informally by the maintainer of this project, and [rough consensus](#consensus) is assumed. Technical decisions that span multiple parts of the project should be discussed and made on the [developer mailing list][devs].
    75  
    76  Decisions are usually made by [rough consensus](#consensus). If no consensus can be reached, the matter may be resolved by [majority vote](#majority-vote).
    77  
    78  ### Governance changes
    79  
    80  Changes to this document are made by Grafana Labs.
    81  
    82  ### Other matters
    83  
    84  Any matter that needs a decision may be called to a vote by any member if they deem it necessary. For private or personnel matters, discussion and voting takes place on the [team mailing list][team], otherwise on the [developer mailing list][devs].
    85  
    86  ## Voting
    87  
    88  The Pyroscope project usually runs by informal consensus, however sometimes a formal decision must be made.
    89  
    90  Depending on the subject matter, as laid out [above](#decision-making), different methods of voting are used.
    91  
    92  For all votes, voting must be open for at least one week. The end date should be clearly stated in the call to vote. A vote may be called and closed early if enough votes have come in one way so that further votes cannot change the final decision.
    93  
    94  In all cases, all and only [team members](#team-members) are eligible to vote, with the sole exception of the forced removal of a team member, in which said member is not eligible to vote.
    95  
    96  Discussion and votes on personnel matters (including but not limited to team membership and maintainership) are held in private on the [team mailing list][team]. All other discussion and votes are held in public on the [developer mailing list][devs].
    97  
    98  For public discussions, anyone interested is encouraged to participate. Formal power to object or vote is limited to [team members](#team-members).
    99  
   100  ### Consensus
   101  
   102  The default decision making mechanism for the Pyroscope project is [rough][rough] consensus. This means that any decision on technical issues is considered supported by the [team][team] as long as nobody objects or the objection has been considered but not necessarily accommodated.
   103  
   104  Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision on the [developers mailing list][devs] at any time and by anyone.
   105  
   106  Consensus decisions can never override or go against the spirit of an earlier explicit vote.
   107  
   108  If any [team member](#team-members) raises objections, the team members work together towards a solution that all involved can accept. This solution is again subject to rough consensus.
   109  
   110  In case no consensus can be found, but a decision one way or the other must be made, any [team member](#team-members) may call a formal [majority vote](#majority-vote).
   111  
   112  ### Majority vote
   113  
   114  Majority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with `[VOTE]`. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.
   115  
   116  Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.
   117  
   118  A vote on a single proposal is considered successful if more vote in favor than against.
   119  
   120  If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. It is not possible to cast an “abstain” vote. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from more than half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
   121  
   122  ### Supermajority vote
   123  
   124  Supermajority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with `[VOTE]`. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.
   125  
   126  Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.
   127  
   128  A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favor.
   129  
   130  If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from at least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
   131  
   132  ## On- / Offboarding
   133  
   134  ### Onboarding
   135  
   136  The new member is
   137  
   138  - added to the list of [team members](#team-members). Ideally by sending a PR of their own, at least approving said PR.
   139  - announced on the [developers mailing list][devs] by an existing team member. Ideally, the new member replies in this thread, acknowledging team membership.
   140  - added to the projects with commit rights.
   141  - added to the [team mailing list][team].
   142  
   143  ### Offboarding
   144  
   145  The ex-member is
   146  
   147  - removed from the list of [team members](#team-members). Ideally by sending a PR of their own, at least approving said PR. In case of forced removal, no approval is needed.
   148  - removed from the projects. Optionally, they can retain maintainership of one or more repositories if the [team](#team-members) agrees.
   149  - removed from the team mailing list and demoted to a normal member of the other mailing lists.
   150  - not allowed to call themselves an active team member any more, nor allowed to imply this to be the case.
   151  - added to a list of previous members if they so choose.
   152  
   153  If needed, we reserve the right to publicly announce removal.
   154  
   155  [announce]: https://github.com/grafana/pyroscope/discussions/categories/announcements
   156  [coc]: https://github.com/grafana/pyroscope/blob/master/CODE_OF_CONDUCT.md
   157  [devs]: https://github.com/grafana/pyroscope/discussions/categories/development
   158  [maintainers]: https://github.com/grafana/pyroscope/blob/master/MAINTAINERS.md
   159  [rough]: https://tools.ietf.org/html/rfc7282
   160  [team]: https://groups.google.com/g/pyroscope-team
   161  [users]: https://github.com/grafana/pyroscope/discussions