[DISCUSS] Clarifying our R-T-C model

[Christopher <ct...@apache.org>]

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

Re: [DISCUSS] Clarifying our R-T-C model

[Christopher <ct...@apache.org>]

I think that's reasonable. Also relevant is this old conversation we
had about "urgent" updates:
https://lists.apache.org/thread.html/3e4b00037eecab92318a510df38c56da5ecddbbe98407d239995bac7@<dev.fluo.apache.org>


On Wed, Sep 4, 2019 at 2:05 PM Keith Turner <ke...@deenlo.com> wrote:

> I am in favor of option #1.  I think a model of RTC with a time limit
> would be nice, where it if there is not activity in 72hrs that its
> approved by lazy consensus.
>
> On Wed, Aug 28, 2019 at 11:54 PM Christopher <ct...@apache.org> wrote:
> >
> > 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
>

Re: [DISCUSS] Clarifying our R-T-C model

[Keith Turner <ke...@deenlo.com>]

I am in favor of option #1.  I think a model of RTC with a time limit
would be nice, where it if there is not activity in 72hrs that its
approved by lazy consensus.

On Wed, Aug 28, 2019 at 11:54 PM Christopher <ct...@apache.org> wrote:
>
> 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