To my tentative counting there seems to be 3 against, 4 pro and a +0. There will definitely be a vote.
If one of the “pros” can start drafting a short doc on how we’d like to do RTC, that’d be awesome. Doesn’t have to be fancy, just something to prevent everyone from interpreting RTC differently. I agree with others who have voiced it that we’d want reviews to be on the dev list. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jul 2, 2017, at 6:04 PM, 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. > > 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. > > - Should all reviews be on the dev list? With Github PRs comments > and JIRA comments, there needs to be a source of truth. > > - Should we fully document the process before we try so we can get > the most value from a 3 month trial? > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com >
