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.