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
The more contributors there are, the harder it will be to satisfy the
current condition (2/3 majority organization vote).
Therefore, this updates the conditions based on the discussion in #4151.
Signed-off-by: Daijiro Fukuda <[email protected]>
Copy file name to clipboardExpand all lines: GOVERNANCE.md
+30-5
Original file line number
Diff line number
Diff line change
@@ -11,21 +11,46 @@ The Fluentd community adheres to the following principles:
11
11
12
12
## Voting
13
13
14
-
The Fluentd project employs "organization voting" to ensure no single organization can dominate the project.
14
+
The Fluentd project employs "Organization Voting" and "Vetoes" to ensure no single organization can dominate the project.
15
+
16
+
For formal votes, we follow these steps.
17
+
18
+
1. Have enough period to discuss the topic so that all discussion members agree that there are no more points to be discussed.
19
+
2. Add a specific statement of what is being voted on to the description of the relevant GitHub issue or pull request.
20
+
3. Declare the start of voting.
21
+
4. Ask maintainers to indicate their yes/no votes on the issue or PR.
22
+
5. Tally the votes and note the outcomes after a suitable period.
23
+
24
+
All the following conditions must be satisfied for the vote to be approved.
25
+
26
+
- No effective objection ballot: See Vetoes, below.
27
+
- At least effective __2-organization__ affirmative vote: See Organization Vote, below.
28
+
- At least effective __3-maintainers__ affirmative vote.
29
+
- At least __2-week__ for voting.
30
+
31
+
Please note that the period for voting should depend on the topic. __2-week__ is merely the minimum period to ensure time for all organizations to say, "Wait! We need more discussion!". The more significant the decision's impact is, the longer the period should be.
32
+
33
+
### Organization Vote
15
34
16
35
Individuals not associated with or employed by a company or organization are allowed one organization vote. Each company or organization (regardless of the number of maintainers associated with or employed by that company/organization) receives one organization vote.
17
36
18
37
In other words, if two maintainers are employed by Company X, two by Company Y, two by Company Z, and one maintainer is an un-affiliated individual, a total of four "organization votes" are possible; one for X, one for Y, one for Z, and one for the un-affiliated individual.
19
38
20
39
Any maintainer from an organization may cast the vote for that organization.
21
40
22
-
For formal votes, a specific statement of what is being voted on should be added to the relevant github issue or PR, and a link to that issue or PR added to the maintainers meeting agenda document. Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time, the votes will be tallied and the outcome noted.
41
+
### Vetoes
42
+
43
+
The proposal is not approved as long as any maintainer votes an effective objection ballot.
44
+
45
+
The maintainer who votes an objection ballot must explain the reason for the objection. Without reasonable justification, the objection ballot is not considered effective.
46
+
47
+
The ballot can be changed during the voting period. For example, if the reason for the objection is solved by discussion or additional fixes, the objection ballot will be withdrawn and changed to an affirmative vote.
23
48
24
49
## Changes in Maintainership
25
50
26
-
New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority organization vote.
51
+
New maintainers are proposed by an existing maintainer and are elected by the formal voting process: See Voting, above.
27
52
28
-
Maintainers can be removed by a 2/3 majority organization vote.
53
+
Maintainers can be removed by the formal voting process: See Voting, above.
29
54
30
55
## Github Project Administration
31
56
@@ -44,7 +69,7 @@ The fluent organization is open to receive new sub-projects under it umbrella. T
44
69
- Data collection
45
70
- Log management
46
71
- Metering
47
-
- Be supported by 2/3 majority of organization
72
+
- Be supported by the formal voting process: See Voting, above.
48
73
49
74
The submission process starts as a Pull Request on Fluentd repository with the required information mentioned above. Once a project is accepted, it's considered a __CNCF sub-project under the umbrella of Fluentd__
0 commit comments