Project governance: Fix voting rule #4160
Conversation
|
Thanks for the reviews! Now I would like to propose taking a vote on this fix according to our current governance policy. The voting rule for this change is not specified, but how about 2/3 organization's votes are sufficient for approval, as usual? |
|
I'm still unsure what type of problems will be picked for voting. But "at least 2 weeks" should be shorter than my expectation. |
|
@tagomoris Thanks for your feedback!
Same as before on this.
As you say, the appropriate period should vary depending on the topic. I assume that we will have an appropriate period for the topic basically. The reason I am suggesting 2 weeks is that this is the minimum period. |
IMHO we won't start voting until the discussion is over (as we are doing in this PR). |
I have the same assumption. |
|
If you all have the same assumption (voting will start when ...), the voting rule should contain it. |
I see, thanks! We'll consider to add such sentence. |
|
@tagomoris Thanks for your review! How about this? (Line breaks are temporarily inserted for readability.) ## Voting
The Fluentd project employs "organization voting" and "Vetoes" to ensure no single organization can dominate the project.
For formal votes, a specific statement of what is being voted on should be added to the relevant GitHub issue or PR.
+The start of voting must be clearly declared.
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.
All the following conditions must be satisfied to approve the formal votes.
- No effective objection ballot: See Vetoes, below.
- At least effective __2-organization__ affirmative vote: See Organization Vote, below.
- At least effective __3-maintainers__ affirmative vote.
- At least __2-week__ for voting.
+Please note that __2-week__ is merely the minimum period to ensure time for all organizations to say,
+"Wait! We need more discussion!".
+We should have enough period to discuss and vote depending on a topic. We should discuss enough on a topic
+before starting voting.
+ |
|
@daipom Not bad, but it doesn't look like the definition of a rule. - No effective objection ballot: See Vetoes, below.
- At least effective __2-organization__ affirmative vote: See Organization Vote, below.
- At least effective __3-maintainers__ affirmative vote.
+ - An explicitly declared beginning of the term of voting.
- At least __2-week__ for voting.
+Voting period should begin at a time when all discussion members agree that there are no more points to be discussed. And voting should have a longer period for the decisions with larger impacts. |
|
Hmm, I think the list consists of the conditions to approve the proposal. What do you all think? I would like to hear a wide range of opinions. |
I feel same thing a bit but not so negative for including this. |
Certainly, we can assume this is also about the voting procedure. Sorry, my explanation may be inaccurate. If I don't think there is any necessity for that (my concept of the list). |
|
Given the points discussed so far, how about rewriting the entire chapter like this? ## Voting
The Fluentd project employs "Organization Voting" and "Vetoes" to ensure no single organization can dominate the project.
For formal votes, we follow these steps.
1. Have enough period to discuss the topic so that all discussion members agree that there are no more points to be discussed.
2. Add a specific statement of what is being voted on to the relevant GitHub issue or PR.
3. Declare the start of voting.
4. Ask maintainers to indicate their yes/no vote on the issue or PR.
5. Tally the votes and note the outcome after a suitable period.
All the following conditions must be satisfied for the vote to be approved.
- No effective objection ballot: See Vetoes, below.
- At least effective __2-organization__ affirmative vote: See Organization Vote, below.
- At least effective __3-maintainers__ affirmative vote.
- At least __2-week__ for voting.
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. |
|
Slightly modified. |
|
I have updated the content of the "Voting" section to #4160 (comment). |
|
@cosmo0920 @tagomoris Could you please confirm the updated contents? |
GOVERNANCE.md
Outdated
| 1. Have enough period to discuss the topic so that all discussion members agree that there are no more points to be discussed. | ||
| 2. Add a specific statement of what is being voted on to the relevant GitHub issue or PR. | ||
| 3. Declare the start of voting. | ||
| 4. Ask maintainers to indicate their yes/no vote on the issue or PR. |
There was a problem hiding this comment.
Should all voting have "yes" and "no"?
If so, "2." must contain the style of voting, like "a specific statement, what is being voted with 'yes' and 'no', what 'yes' means and 'no' means, ...".
Otherwise, this "4." should define the way to indicate the options. Alphabetical signs (A/B/C/...)? Reactions?
There was a problem hiding this comment.
This also should define how to record the votes from members. Should it be public or private? With account names or anonymously?
There was a problem hiding this comment.
Most of these texts follow the current ones.
Line 22 in dc7e4b2
This too.
Maintainers should indicate their yes/no vote on that issue or PR
Do you mean we should fix it on this occasion?
I thought it didn't need to be the focus of this PR.
There was a problem hiding this comment.
Maybe we should decide the voting style later in the dedicated issue.
In my opinion, we have to write down the guideline to show yes/no voting.
:+1: and :-1: signs should be enough in the most cases.
So, my suggestions is:
Maintainers should indicate their yes/no votes with formally defined signs. The signs must be defined when the voting is started.
Or, we should define something like similar sentences.
There was a problem hiding this comment.
I agree about making such improvements, as @tagomoris and @cosmo0920 say.
I think it should be made separately from this PR since this PR is already a major rule revision.
GOVERNANCE.md
Outdated
| 2. Add a specific statement of what is being voted on to the relevant GitHub issue or PR. | ||
| 3. Declare the start of voting. | ||
| 4. Ask maintainers to indicate their yes/no vote on the issue or PR. | ||
| 5. Tally the votes and note the outcome after a suitable period. |
There was a problem hiding this comment.
Most of these texts follow the current ones.
Line 22 in dc7e4b2
This too.
after a suitable period of time, the votes will be tallied and the outcome noted.
I think the subject is the person who proposes "Voting".
Currently, the subject is not specified, and I don't see a problem with that.
Do you want to specify it on this occasion?
There was a problem hiding this comment.
In my idea, this kind of document should define those things explicitly. We can easily imagine the situation:
- a maintainer (A) started a voting
- there are minimum "yes" 2 weeks later, but A is really busy
- A is still busy and does not respond to the voting issue 4 weeks later
What will happen in this situation? Another maintainer can close this voting or not?
My idea is, we should make rules as explicit as possible if we have them.
There was a problem hiding this comment.
I see. Thanks for the explanation.
I understand that we can improve the document from that perspective,
but I think it should be made separately from this PR, as well as #4160 (comment).
In this PR, I want to solve #4151.
Other than the threshold of the conditions required to approve the proposal, I keep the essential contents as unchanged as possible.
I think the problem with that situation comes from the current document, not from this revision.
We should discuss it separately from this revision.
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 fluent#4151. Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
|
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 7 days |
|
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 7 days |
|
This PR was automatically closed because of stale in 7 days |
Which issue(s) this PR fixes:
Fixes #4151
What this PR does / why we need it:
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
These new conditions refer to Apache Voting Process:
Docs Changes:
Not needed.
Release Note:
Not needed.
Voting:
I would like to propose taking a vote on this fix according to our current governance policy.
The voting rule for this change is not specified, but how about 2/3 organization's votes are sufficient for approval, as usual?
The total number of organizations is 8 and we need at least 6 votes to satisfy the majority of 2/3.