You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: governance.md
+11-10
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,8 @@
1
1
# Virtual Kubelet Governance
2
2
3
-
The following document outlines how the virtual kubelet governance operates. Much of this document has been repurposed from Helm's governance guidelines.
3
+
The following document outlines how the virtual kubelet governance operates. Virtual kubelet relies on two components, the pluggable interface and the providers that "plug-in."
4
4
5
-
Virtual kubelet relies on two components, the pluggable interface and the providers that "plug-in."
6
-
7
-
## Maintainers Structure
8
-
9
-
There are two levels of maintainers for virtual kubelet. The virtual kubelet core maintainers oversee the overall project and it's health.
5
+
There are two levels of maintainers for virtual kubelet, core maintainers and project or provider maintainers.
10
6
11
7
### Virtual Kubelet Core Maintainers
12
8
@@ -28,16 +24,18 @@ The core maintainers have to match the following criterea:
28
24
* Any project maintainer is eligible to become a core maintainer
29
25
* An core maintainer can step down by emailing our maintainer list (LINK TBA)
30
26
* Core maintainers must remain active, and if they are unresponsive for > 3 months maintainership unless a super-majority of the other core maintainers agree to extend the period to greater than 3 months.
31
-
* When there is an opening for an core maintainer anyone can nominate a project maintainer as a replacement.
27
+
* When there is an opening for an core maintainer anyone can nominate candidate as a replacement.
32
28
* The nomination period is one month starting the day after the position becomes avaliable.
33
29
* The nomination must be via the Virtual Kubelet provider mailing list.
34
-
* When the nominated individual agrees to be a canidate, the project maintainers may vote.
30
+
* When the nominated individual agrees to be a canidate, the project maintainers and the current core maintainers may vote.
35
31
* The voting period will be a minimum of 7 days and will close when a majority of project maintainers have voted.
32
+
* Each maintainer will get 1 vote, yes or no, and depending on the majority the candidate will either become a core maintainer or not. Maintainers will vote through a election form (Office forms or Google forms).
33
+
* After a maximum of 2 weeks after the voting period started, the votes will be counted up and the status of the vote will be sent out to the project and core maintainers.
36
34
* When an org maintianer steps down they become an emeritus maintainer.
37
35
38
36
### Project/Provider Maintainers
39
37
40
-
Project maintainers are responsible for maintaing the release cycle of virtual kubelet and the specific operations they own. Techincal decisions can be made by the project maintainers.
38
+
Project maintainers are responsible for maintaing the release cycle of virtual kubelet and the specific operations they own. Techincal decisions can be made by the project maintainers. There can be two maintainers per provider.
41
39
42
40
When maintainers need to make a decisions there are two ways decisions are made, unless described elsewhere.
43
41
@@ -47,6 +45,9 @@ When a consensus cannot be found a maintainer can call for a majority vote on a
47
45
48
46
The following must be voted on:
49
47
50
-
* Removing a maintainer for any other reason other than inactivity
48
+
* Removing a core, or project maintainer for any other reason other than inactivity
51
49
* Licensing and intellectual property changes (includes new logos, wordmarks)
50
+
* Adding a new core maintainer or project maintainer. To successfully vote a new maintainer in there must be a super majority of 2/3s of the vote cast in favor of the candidate.
51
+
52
+
If a project maintainer remains inactive for a period of 2 months or more, they will get a notice of issues to close or work on that are relevant to their provider. If they do not make any significant progress (progress is determined by core maintainers) then they will be labeled as an inactive provider and after 6 months of inactivity will be subject to removal from the Virtual Kubelet organization.
0 commit comments