On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <david.blev...@gmail.com> wrote:
> There’s a discussion on the private list on this topic, but given the > recent thread I think it makes sense to move that here. > > The vote would be only on this question: > > - Is RTC worth trying for 3 months? (+1,+/-0,-1) > > I’ve seen some voices in favor, but do not want to propose a vote > without a heads-up. Specifically, even if many people like the idea > we should talk about how we want to do it. > > # Review-than-commit > > For those that do not know, Review-than-commit is essentially what > Github Pull Requests are. Prior to github, Apache describes them as: > > - Commit policy which requires that all changes receive consensus > approval in order to be committed. > > I think we’ve seen evidence that: > > - Slowing ourselves down can be a good thing. > > - Moving ahead after discussion is a good thing. Discussion should > precede even the first commit. > > - More eyes and talk around commits can help documentation efforts. > > - As 3 +1s are required, a one-to-one conversation with no one else > included is naturally discouraged. > > # Trial basis > > My thought is to go RTC for 3 months as a trial. After 3 months, no > action means we revert back to our present CTR. A new vote would be > required to continue RTC in any form, as-was or modified. > Unless its obviously unanimous that everyone dislikes RTC at the end of 3 months, I'd suggest we call a vote to decide how to proceed. Not quite sure how that fits into +1/0/-1 however, so may be it should be a 3 month trial, followed by 2 weeks for review and discussion (during which we'd still be RTC) and then a vote? > > The trial-basis is to acknowledge that we are voting on a guess of > potential benefits. This allows us to "try before we buy" and the > vote really comes down to if we want to try. We need not make a > decision based on other people's experience and have a means to gain > our own experience with a built-in escape clause that triggers lazily. > > RTC may sound like a good idea, but our implemention of it may be bad > in practise. It may sound like a bad idea, but we may discover > positives we hadn't anticipated. We don't currently know. > > # How would we do it? > > Some things that would be good to discuss: > > - How could we use github pull requests? Other communities do use > them and I suspect there are options we have not explored. > I'd be in favour of that, as that process seems to be very well known. > > - Should all reviews be on the dev list? With Github PRs comments > and JIRA comments, there needs to be a source of truth. > I think both the discussion and review should happen on the dev list. GH/JIRA comments are fine in themselves, but there may be (should be) discussion on dev@ before a PR is opened, so having all that discussion in one place is important for me. Even if GH comments prove popular, its not hard to copy/paste it to dev@ with a link. > > - Should we fully document the process before we try so we can get > the most value from a 3 month trial? > I'd be in favour of discussing and documenting. > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >
