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.
For example, If someone proposed an idea to release Fluentd 2.0 in mid-December, it could get low intention from members in 2 weeks.

@tagomoris Thanks for your feedback!

I'm still unsure what type of problems will be picked for voting.

Same as before on this.

"at least 2 weeks" should be shorter than my expectation.
For example, If someone proposed an idea to release Fluentd 2.0 in mid-December, it could get low intention from members in 2 weeks.

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.
This is designed to prevent people from completing their votes too quickly (no time for saying "Wait!").
This doesn't say a decision should be made in two weeks.

For example, If someone proposed an idea to release Fluentd 2.0 in mid-December, it could get low intention from members in 2 weeks.

IMHO we won't start voting until the discussion is over (as we are doing in this PR).
In your example, we never start voting until we get opinions of when Fluentd 2.0 should be released from each active developers.
Still do you think 2 weeks is too short? If so, how long do you think it's appropriate?

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.

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.
I would add items to the list, for example:

  - 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.
It seems to me that An explicitly declared beginning of the term of voting. is a voting procedure, not a condition.
So, I feel something strange adding it to this list.

What do you all think? I would like to hear a wide range of opinions.

It seems to me that An explicitly declared beginning of the term of voting. is a voting procedure, not a condition.

I feel same thing a bit but not so negative for including this.
Because the next item is also about voting procedure:

  - At least __2-week__ for voting.

It seems to me that An explicitly declared beginning of the term of voting. is a voting procedure, not a condition.

I feel same thing a bit but not so negative for including this. Because the next item is also about voting procedure:

  - At least __2-week__ for voting.

Certainly, we can assume this is also about the voting procedure.
(I think it can also be viewed as a condition that must be satisfied by elapsed time during voting, though)

Sorry, my explanation may be inaccurate.
Perhaps the point I felt strange with was the following.

If An explicitly declared beginning of the term of voting. were not satisfied in advance, the voting would not have begun in the first place.
It seems I was thinking of "conditions" as conditions that had to be satisfied after starting voting.

I don't think there is any necessity for that (my concept of the list).
I want to prioritize a form that many people will find easy to understand.

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.

#4160 (comment)

Slightly modified.

I have updated the content of the "Voting" section to #4160 (comment).

@cosmo0920 @tagomoris Could you please confirm the updated contents?

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