Project governance: Fix voting rule

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.

These new conditions refer to Apache Voting Process:

* https://www.apache.org/foundation/voting#apache-voting-process

Signed-off-by: Daijiro Fukuda <[email protected]>

Author: daipom

GOVERNANCE.md

@@ -11,21 +11,38 @@ The Fluentd community adheres to the following principles:
 
 ## Voting
 
-The Fluentd project employs "organization voting" to ensure no single organization can dominate the project.
+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. 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.
+
+### Organization Vote
 
 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.
 
 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.
 
 Any maintainer from an organization may cast the vote for that organization.
 
-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.
+### Vetoes
+
+The proposal is not approved as long as any maintainer votes an effective objection ballot.
+
+The maintainer who votes an objection ballot must explain the reason for the objection. Without reasonable justification, the objection ballot is not considered effective.
+
+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.
 
 ## Changes in Maintainership
 
-New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority organization vote.
+New maintainers are proposed by an existing maintainer and are elected by the formal voting process: See Voting, above.
 
-Maintainers can be removed by a 2/3 majority organization vote.
+Maintainers can be removed by the formal voting process: See Voting, above.
 
 ## Github Project Administration
 
@@ -44,7 +61,7 @@ The fluent organization is open to receive new sub-projects under it umbrella. T
   - Data collection
   - Log management
   - Metering
-- Be supported by 2/3 majority of organization
+- Be supported by the formal voting process: See Voting, above.
 
 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__