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,36 @@ 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.
 
 ## 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 +59,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__