github.com/kiali/kiali@v1.84.0/GOVERNANCE.md (about)

     1  # Kiali Governance
     2  
     3  This document defines governance policies for the Kiali project.
     4  
     5  ## Maintainers
     6  
     7  Kiali Maintainers have write access to the [Kiali GitHub repositories](https://github.com/kiali).
     8  They can merge their own patches or patches from others. Maintainers collectively manage the project's
     9  resources and contributors. If needed, maintainers are elegible to become admins of specific repositories, or owners
    10  of the Kiali organization.
    11  
    12  These privileges are granted with an expectation of responsibility: maintainers care about the Kiali project and want to help it grow and improve. Above the ability to contribute changes, a maintainer has demonstrated the ability to collaborate well with the team, assign appropriate code reviewers, contribute high-quality code, and be thorough and timely with fixes, tests and documentation.
    13  
    14  A maintainer is a contributor to the Kiali project's success and a citizen helping the project succeed.
    15  
    16  Current list of maintainers (alphabetically ordered):
    17  
    18  - [aljesusg](https://github.com/aljesusg)
    19  - [ferhoyos](https://github.com/ferhoyos)
    20  - [hhovsepy](https://github.com/hhovsepy)
    21  - [jmazzitelli](https://github.com/jmazzitelli)
    22  - [josunect](https://github.com/josunect)
    23  - [leandroberetta](https://github.com/leandroberetta)
    24  - [nrfox](https://github.com/nrfox)
    25  - [xunzhuo](https://github.com/xunzhuo)
    26  
    27  ### Becoming a Maintainer
    28  
    29  To become a Maintainer you need to demonstrate the following:
    30  
    31  - commitment to the project
    32    - participate in discussions, contributions, code reviews for 3 months or more,
    33    - perform code reviews for 10 non-trivial pull requests,
    34    - contribute 10 non-trivial pull requests and have them merged,
    35  - ability to write high quality code and/or documentation,
    36  - ability to collaborate with the team,
    37  - understanding of team policies and processes,
    38  - understanding of the project's code base, and coding and documentation style.
    39  
    40  A new maintainer must be proposed by an existing maintainer by opening a pull request
    41  modifying the maintainers list to add the new proposed maintainer, or via a [GitHub
    42  discussion](https://github.com/kiali/kiali/discussions/new) under the Governance category.
    43  The following information must be provided:
    44  
    45  - nominee's GitHub username,
    46  - an explanation of why the nominee should be a maintainer,
    47  - a list of links to non-trivial pull requests (top 10) authored by the nominee.
    48  
    49  Two other maintainers need to second the nomination. If no one objects in 5 working days (U.S.), the nomination is accepted. If anyone objects or wants more information, the maintainers discuss and usually come to a consensus (within the 5 working days). If issues can't be resolved, there's a simple majority vote among current maintainers.
    50  
    51  ## Testers
    52  
    53  Kiali testers dedicate time and resources to ensure that the Kiali project is
    54  delivered with good quality, by actively trying pull requests to find bugs,
    55  performance issues and any other kind of defect. Testers may also write manual or
    56  automated tests. The focus is on "System testing" and "Integration testing",
    57  although it is possible to do simple sanity, smoke and regression testing, or
    58  simply running existent automated tests if that is enough for a certain code change.
    59  
    60  Testers are granted the same privileges as Maintainers, and are also invited to become
    61  a member of the Kiali organization. This is in good faith of not performing tasks of a
    62  Maintainer.
    63  
    64  Testers do not need to be Maintainers. Also, Maintainers do not need to be Testers. Yet,
    65  both roles aren't mutually exclusive.
    66  
    67  Current list of testers (alphabetically ordered):
    68  
    69  - [FilipB](https://github.com/FilipB)
    70  - [matejnesuta](https://github.com/matejnesuta)
    71  - [mkralik3](https://github.com/mkralik3)
    72  - [pbajjuri20](https://github.com/pbajjuri20)
    73  - [prachiyadav](https://github.com/prachiyadav)
    74  - [ScriptingShrimp](https://github.com/ScriptingShrimp)
    75  
    76  ### Becoming a Tester
    77  
    78  To become a Tester you need to:
    79  
    80  - actively participate in testing code changes of the Kiali project
    81    - testing pull requests for 3 months or more,
    82    - find 5 non trivial defects in Kiali,
    83    - occassionally, do testing over `master` branches to find broken features
    84  - ability to collaborate with the team,
    85  - ability to document testing procedures of Kiali features and to update existing documentation if features change,
    86  - understanding of team policies and processes.
    87  
    88  You can propose yourself to apply for the Tester role, or a Maintainer can do it for you.
    89  Proposals must be posted by opening a pull request
    90  modifying the testers list to add the new proposed tester, or via
    91  a [GitHub discussion](https://github.com/kiali/kiali/discussions/new) under the
    92  Governance category. The following information must be provided:
    93  
    94  - nominee's GitHub username
    95  - a list of pull requests (top 5) tested by the nominee.
    96  - a list of documented test cases (if any)
    97  
    98  Formalization of the Tester role is granted if a simple majority vote
    99  among current maintainers succeeds.
   100  
   101  ## Leaders
   102  
   103  Kiali leaders are Maintainers who have a broad knowledge about the Kiali project, its goals and vision.
   104  They may also be aware on how the ecosystem related to Kiali is evolving, and may also be aware of related projects.
   105  Thus, they are able to guide and mentor other Maintainers, give direction, and set priorities to the Kiali project.
   106  
   107  Current list of leaders (alphabetically ordered):
   108  
   109  - [jshaughn](https://github.com/jshaughn)
   110  
   111  ### Becoming a Leader
   112  
   113  To become a Leader, you must first be a Maintainer. Then, a new Leader must be proposed
   114  by an existing Maintainer by opening a pull request modifying the leaders list to add the new
   115  proposed leader, or via a by opening a [GitHub discussion](https://github.com/kiali/kiali/discussions/new)
   116  under the Governance category. The following information must be provided:
   117  
   118  - nominee's GitHub username,
   119  - an explanation of why the nominee should be a leader.
   120  
   121  Leadership is granted if a simple majority vote among current maintainers succeeds.
   122  
   123  ## Inactivity
   124  
   125  It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a lost of trust in the project.
   126  
   127  - Inactivity is measured by:
   128    - Periods of no contributions for longer than 4 months
   129    - Periods of no communication for longer than 4 months
   130  - Consequences of being inactive include:
   131    - Involuntary removal or demotion
   132    - Being asked to move to Emeritus status
   133  
   134  ## Involuntary Removal or Demotion
   135  
   136  Involuntary removal/demotion of a contributor happens when requirements for a certain role aren't being met. This may include repeated patterns of inactivity, extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new contributors to step in.
   137  
   138  Involuntary removal or demotion is handled through a vote by simple majority of the current Maintainers.
   139  
   140  ## Stepping Down/Emeritus Process
   141  
   142  If and when contributors commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project).
   143  
   144  Contact the Maintainers about changing to Emeritus status, or reducing your contributor level.
   145  
   146  ### Emeritus contributors
   147  
   148  - [abonas](https://github.com/abonas)
   149  - [beaumorley](https://github.com/beaumorley)
   150  - [burmanm](https://github.com/burmanm)
   151  - [cfcosta](https://github.com/cfcosta)
   152  - [gbaufake](https://github.com/gbaufake)
   153  - [israel-hdez](https://github.com/israel-hdez)
   154  - [josejulio](https://github.com/josejulio)
   155  - [jotak](https://github.com/jotak)
   156  - [jstickler](https://github.com/JStickler)
   157  - [jpkrohling](https://github.com/jpkrohling)
   158  - [kevinearls](https://github.com/kevinearls)
   159  - [lucasponce](https://github.com/lucasponce)
   160  - [lwrigh](https://github.com/lwrigh)
   161  - [maltron](https://github.com/maltron)
   162  - [mattmahoneyrh](https://github.com/mattmahoneyrh)
   163  - [mtho11](https://github.com/mtho11)
   164  - [mwringe](https://github.com/mwringe)
   165  - [pavolloffay](https://github.com/pavolloffay)
   166  - [serenamarie125](https://github.com/serenamarie125)
   167  - [skondkar](https://github.com/skondkar)
   168  - [xeviknal](https://github.com/xeviknal)
   169  
   170  ## Voting
   171  
   172  While most business in Kiali project is conducted by "lazy consensus", periodically
   173  the Maintainers may need to vote on specific actions or changes.
   174  A vote can be taken on pull requests proposing project changes, or via a
   175  [a GitHub discussion](https://github.com/kiali/kiali/discussions/new).
   176  If there are security or conduct matters, voting can take place in private meetings.
   177  Any Maintainer or Tester may demand a vote be taken.
   178  
   179  Most votes require a simple majority of all Maintainers to succeed. Changes
   180  to the Governance require a 2/3 vote of all Maintainers.
   181  
   182  Kiali Testers also have a voice in voting although their vote is not mandatory.
   183  
   184  Unless some process specifies something different, once a vote starts Maintainers (and Testers)
   185  must give their vote within 7 working days (U.S.)
   186  
   187  ## Other Changes
   188  
   189  Unless specified above, all other changes to the project require a 2/3 majority vote.
   190  Additionally, any maintainer or tester may request that any change require a 2/3 majority vote.