Hi Devs, I noticed that https://fluo.apache.org/how-to-contribute/ links to https://www.apache.org/foundation/glossary.html#ReviewThenCommit to describe R-T-C. That link references https://www.apache.org/foundation/glossary.html#ConsensusApproval which describes a voting procedure that requires 3 +1s and no vetoes. Voting periods are at least 72 hours at ASF, to allow sufficient time for feedback. So, we are currently not following the foundation's definition of review-then-commit.
Rather, what we are doing is something else entirely. Our procedure is to ensure that at least one committer (other than the author) has looked over a change and has had the opportunity to examine it and has no objections. There is no vote, and certainly not a requirement for 3 +1s. Actually, it's not even clear to me that we require the reviewer to be a committer, although I think I've been assuming it would be. I think this model is fine, but since it doesn't align to the ASF definition, there's a few things we can or should do to bring some clarity to our R-T-C model: 1. We can provide our own definition of review-then-commit, 2. We can start actually following the definition from the Foundation, or 3. We can switch to a commit-then-review model formally, while informally still encouraging reviews first (obviously, non-committers have to have stuff reviewed still) I'm in favor of option #1... but option #3 is appealing to me, because it's how we operate in Accumulo right now, and I'm starting to get concerned that we don't have a sufficient number of reviewers active right now. We're still pretty small in number, and it might be hard to get reviews at times when people's activity levels fluctuate downward, which can stall work. (Growing our size is a problem to be addressed, but that's off-topic for this thread.) Thoughts? Christopher
