Maybe your experience is different but I find it hard enough to get even
one person to review my pull requests. I've resorted to merging minor
changes without a review a few times due to lack of response.
On 5/30/19 3:51 PM, Owen Nichols wrote:
It seems common for Geode PRs to get merged with only a single green checkmark
in GitHub.
According to https://www.apache.org/foundation/voting.html we should not be
merging PRs with fewer than 3 green checkmarks.
Consensus is a fundamental value in doing things The Apache Way. A single +1
is not consensus. Since we’re currently discussing what it takes to become a
committer and what standards a committer is expected to uphold, it seems like a
good time to review this policy.
GitHub can be configured to require N reviews before a commit can be merged.
Should we enable this feature?
-Owen
VOTES ON CODE MODIFICATION
<https://www.apache.org/foundation/voting.html#votes-on-code-modification>
For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are
vetos <https://www.apache.org/foundation/voting.html#Veto> and kill the
proposal dead until all vetoers withdraw their -1 votes.
Unless a vote has been declared as using lazy consensus
<https://www.apache.org/foundation/voting.html#LazyConsensus> , three +1 votes
are required for a code-modification proposal to pass.
Whole numbers are recommended for this type of vote, as the opinion being
expressed is Boolean: 'I approve/do not approve of this change.'
CONSENSUS GAUGING THROUGH SILENCE
<https://www.apache.org/foundation/voting.html#LazyConsensus>
An alternative to voting that is sometimes used to measure the acceptability of
something is the concept of lazy consensus
<https://www.apache.org/foundation/glossary.html#LazyConsensus>.
Lazy consensus is simply an announcement of 'silence gives assent.’ When
someone wants to determine the sense of the community this way, it might do so
with a mail message such as:
"The patch below fixes GEODE-12345; if no-one objects within three days, I'll assume
lazy consensus and commit it."
Lazy consensus cannot be used on projects that enforce a review-then-commit
<https://www.apache.org/foundation/glossary.html#ReviewThenCommit> policy.
