RTC is Consensus Approval and does not need 72h, just 3+1 in any amount of time.
On 7 July 2017 at 16:33, Andy Gumbrecht <agumbre...@tomitribe.com> wrote: > Those quotes are from Apache. > > On 7 July 2017 at 16:30, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > >> What Mark meant is if we go through a "vote" then we need to comply to ASF >> rules. Otherwise anything is up to the project and not a "vote". #semantic >> ;) >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>: >> >> > A release is: >> > >> > Majority Approval >> > Refers to a vote (sense 1) which has completed with at least three >> binding >> > +1 votes and more +1 votes than -1 votes - You have to wait 72h. >> > >> > On 7 July 2017 at 16:25, Andy Gumbrecht <agumbre...@tomitribe.com> >> wrote: >> > >> > > This is not a vote for a release, if you get 3+1s within a minute then >> > you >> > > don't have to wait 72h. It is 'Consensus Approval'. >> > > >> > > Consensus Approval >> > > 'Consensus approval' refers to a vote (sense 1) which has *completed >> > *with >> > > at least three binding +1 votes and no vetos >> > > >> > > On 7 July 2017 at 16:19, Mark Struberg <strub...@yahoo.de.invalid> >> > wrote: >> > > >> > >> You know how voting works at the ASF? ;) >> > >> >> > >> Either have a VOTE - with all it's implciations - or not. >> > >> >> > >> >> > >> LieGrue, >> > >> strub >> > >> >> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht < >> > agumbre...@tomitribe.com >> > >> >: >> > >> > >> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for >> a >> > >> 2+1. >> > >> > >> > >> > As soon as whatever is decided is counted then the commit occurs. >> That >> > >> > could be within a few minutes. >> > >> > >> > >> > Andy. >> > >> > >> > >> > On 7 July 2017 at 14:59, Mark Struberg <strub...@yahoo.de.invalid> >> > >> wrote: >> > >> > >> > >> >> +1 well said, Jeff! >> > >> >> >> > >> >> LieGrue, >> > >> >> strub >> > >> >> >> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender < >> jgenen...@apache.org >> > >: >> > >> >>> >> > >> >>> Lurking on this, I have to underscore what Mark said. >> > >> >>> >> > >> >>> Andy, you are pretty correct on nearly every point that you made. >> > But >> > >> >> the things stated are more of refining your current process rather >> > than >> > >> >> taking RTC for current committers. You already had RTC with PRs >> from >> > >> >> outsiders. If that slipped in, it just means that a trusted >> > committer >> > >> >> didn’t do their job. It happens. Breaking a trunk build for a >> day >> > >> (or >> > >> >> even a week) is ok. Thats why its trunk. I cannot tell you how >> many >> > >> times >> > >> >> I have downloaded a project’s trunk and things weren’t quite >> right. >> > >> >>> >> > >> >>> Relative to what prompted this RTC discussion again, I think >> things >> > >> got >> > >> >> emotional and people slipped up afterwards. The beauty of all >> this >> > is >> > >> all >> > >> >> parties shook hands and made up. Problem was more-or-less solved >> and >> > >> the >> > >> >> project was back on track. >> > >> >>> >> > >> >>> IMHO, taking on RTC is punitive. It means that you need to reset >> > the >> > >> >> way you do things because you cannot do it yourselves. Do you >> think >> > >> you >> > >> >> are at that point? It didn’t look that way to me… but its >> certainly >> > >> >> possible based on what is being done behind the scenes. >> > >> >>> >> > >> >>> Just some food for thought. >> > >> >>> >> > >> >>> Jeff >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht < >> > agumbre...@tomitribe.com >> > >> > >> > >> >> wrote: >> > >> >>>> >> > >> >>>> The main issue here is that both new and existing developers on >> the >> > >> >> project >> > >> >>>> need breathing space in order to thrive and grow. >> > >> >>>> >> > >> >>>> The period between releases is for everyone and not just the >> few. >> > It >> > >> is >> > >> >>>> only 99.99% OK for one or two individuals. Everyone else seems >> to >> > be >> > >> >>>> suffering behind closed doors or in silence, or fighting >> constant >> > >> >> mobbing >> > >> >>>> to the point where 'our' fun project has become too tedious for >> > many >> > >> >>>> people's free time. >> > >> >>>> >> > >> >>>> I'm not going to focus on the reasons behind the "Suffocating >> > >> >> development >> > >> >>>> environment" thread, only that it was the web 'staging' >> environment >> > >> used >> > >> >>>> for a review, but treated like it was North Korea production >> > nuclear >> > >> >> bomb >> > >> >>>> code. It should have been handled better. We found a resolution >> the >> > >> long >> > >> >>>> way round (github web hosting). >> > >> >>>> >> > >> >>>> However, the situation has evolved where existing committers >> don't >> > >> >> discuss, >> > >> >>>> create or assign tickets because they are literally mobbed or >> > >> hijacked >> > >> >> by >> > >> >>>> another committer within minutes. >> > >> >>>> That is currently so predictable that it has become a kind of >> > >> un-funny >> > >> >> joke >> > >> >>>> even outside of our community. Tickets are often created >> 'after' a >> > >> >> commit >> > >> >>>> with a closed status. >> > >> >>>> >> > >> >>>> What needs to change is: >> > >> >>>> >> > >> >>>> Committers need to be able to take and work on a ticket in peace >> > over >> > >> >>>> several days or even weeks, without being trumped due to >> impatience >> > >> or >> > >> >> the >> > >> >>>> notion of 'I know better'. >> > >> >>>> Many can only dedicate a finite amount of time, but still need >> to >> > >> push >> > >> >>>> in-progress work regularly - Git makes that easier now. The >> review >> > >> >> process >> > >> >>>> should be a fun and helpful thing. >> > >> >>>> >> > >> >>>> Committers and new contributors should be encouraged to take >> > tickets. >> > >> >>>> >> > >> >>>> At most, impatience should be directed towards discussion, >> > motivation >> > >> >> and >> > >> >>>> encouragement - It's about team play on a global scale, not 'My >> way >> > >> or >> > >> >> the >> > >> >>>> highway'. >> > >> >>>> >> > >> >>>> It is often not viable to test the whole project for a small >> change >> > >> - It >> > >> >>>> takes well over two hours. The buildbot is like our buzzer that >> > says >> > >> >> "fix >> > >> >>>> me" - Not revert me, or trash me, or trump me. >> > >> >>>> >> > >> >>>> Note to self: Why does the word 'trump' feel like it's been >> > hijacked >> > >> by >> > >> >>>> someone?... >> > >> >>>> >> > >> >>>> The 'buzzer' should be allowed to ring for a day or two, again >> not >> > >> >> everyone >> > >> >>>> stays up the whole night ready to trash a breaking commit. They >> go >> > to >> > >> >>>> sleep, get up, go to work, get home, eat... and then check the >> > build >> > >> if >> > >> >>>> they have time the next day. >> > >> >>>> >> > >> >>>> It is OK to break the build. Everyone gets to have a go at that >> and >> > >> >> learn >> > >> >>>> from it. Over and over. We don't release broken builds, only the >> > good >> > >> >> ones >> > >> >>>> in-between. >> > >> >>>> >> > >> >>>> Any disagreement at any level goes to a vote. The majority wins. >> > >> >>>> >> > >> >>>> I think a trial RTC policy can help achieve these goals as it >> > forces >> > >> >>>> community involvement - A good thing. >> > >> >>>> >> > >> >>>> Andy. >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> On 5 July 2017 at 23:02, Jonathan Gallimore < >> > >> >> jonathan.gallim...@gmail.com> >> > >> >>>> wrote: >> > >> >>>> >> > >> >>>>> Are you referring to the changes in the "Suffocating >> development >> > >> >>>>> environment" thread, or something else? In my view, the patch >> Andy >> > >> >> applied >> > >> >>>>> last week had very limited review (1 person), and the revert >> had >> > no >> > >> >> review. >> > >> >>>>> We've seen contributions come in through GitHub PRs (which is >> > >> great), >> > >> >> but >> > >> >>>>> also applied directly to the repository by committers without >> > >> further >> > >> >>>>> discussion (less great), effectively meaning just 1 reviewer - >> I'm >> > >> not >> > >> >> sure >> > >> >>>>> that's really the spirit of RTC. >> > >> >>>>> >> > >> >>>>> Jon >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> On Wed, Jul 5, 2017 at 6:06 PM, Mark Struberg >> > >> >> <strub...@yahoo.de.invalid> >> > >> >>>>> wrote: >> > >> >>>>> >> > >> >>>>>> As far as I recall the original issue was initially caused by >> > >> >> applying a >> > >> >>>>>> PR. >> > >> >>>>>> That means we had this very issue with a commit which had RTC >> in >> > >> >> place. >> > >> >>>>>> >> > >> >>>>>> Draw your own conclusions... >> > >> >>>>>> >> > >> >>>>>> LieGrue, >> > >> >>>>>> strub >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>>>> Am 05.07.2017 um 14:26 schrieb Romain Manni-Bucau < >> > >> >>>>> rmannibu...@gmail.com >> > >> >>>>>>> : >> > >> >>>>>>> >> > >> >>>>>>> Hmm, let put it in a raw way: can we skip the asf list on >> these >> > >> >>>>>>> discussions? Literally means can be use the way everybody >> uses >> > for >> > >> >> RTC, >> > >> >>>>>> ie >> > >> >>>>>>> github PRs *only*. If not I don't see the point to use it >> since >> > >> >>>>>>> contributors we got are mainly github/jira and I think it is >> > >> natural >> > >> >>>>> as a >> > >> >>>>>>> contributor to use these media instead of the list. >> > >> >>>>>>> >> > >> >>>>>>> Can we somehow merge the github flow with the mailing in a >> > >> smoother >> > >> >> way >> > >> >>>>>>> than the jira integration - and even make jira optional? If >> not >> > >> I'm >> > >> >>>>>> pretty >> > >> >>>>>>> sure it doesn't need any more evaluation, if we can then it >> can >> > be >> > >> >>>>> great >> > >> >>>>>> to >> > >> >>>>>>> benefit from github well known flow. >> > >> >>>>>>> >> > >> >>>>>>> To rephrase it to maybe make it even more explicit: it is not >> > >> about >> > >> >>>>>> making >> > >> >>>>>>> our - as committers - work easier but making contributions >> > easier. >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> Romain Manni-Bucau >> > >> >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > >> >>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > >> >>>>>>> <http://rmannibucau.wordpress.com> | Github < >> > >> >>>>>> https://github.com/rmannibucau> | >> > >> >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE >> > >> Factory >> > >> >>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >> > >> >>>>>>> >> > >> >>>>>>> 2017-07-05 13:23 GMT+02:00 Jonathan Gallimore < >> > >> >>>>>> jonathan.gallim...@gmail.com> >> > >> >>>>>>> : >> > >> >>>>>>> >> > >> >>>>>>>> As I see it, while the recent issue with the documentation >> was >> > >> >>>>> probably >> > >> >>>>>> the >> > >> >>>>>>>> trigger for discussing RTC on dev@, I think the general >> idea >> > is >> > >> >>>>>> actually >> > >> >>>>>>>> to >> > >> >>>>>>>> get more discussion going on around features and fixes, and >> to >> > >> >>>>> encourage >> > >> >>>>>>>> more interaction in the review process. We are struggling >> as a >> > >> >>>>>> community in >> > >> >>>>>>>> that regard. The documentation issue might now be "fixed" by >> > >> using >> > >> >>>>>> personal >> > >> >>>>>>>> html area usage, but I still think RTC is worthy of >> > >> consideration. >> > >> >> We >> > >> >>>>>> are >> > >> >>>>>>>> seeing some contributions come in from new contributors and >> we >> > >> have >> > >> >> an >> > >> >>>>>>>> opportunity to nurture them through this discussion and >> review >> > >> >>>>> process. >> > >> >>>>>>>> >> > >> >>>>>>>> Incidentally, if we trialled RTC and saw improvements, I'd >> vote >> > >> to >> > >> >>>>> keep >> > >> >>>>>> it >> > >> >>>>>>>> after 3 months and not "safely return back". If we don't see >> > >> >>>>>> improvements, >> > >> >>>>>>>> I'd be trying to think of some other ideas to try. I think >> we'd >> > >> all >> > >> >> be >> > >> >>>>>> open >> > >> >>>>>>>> to other suggestions as well, but I'm of the view that if we >> > >> don't >> > >> >> try >> > >> >>>>>>>> something, then potentially nothing will change. >> > >> >>>>>>>> >> > >> >>>>>>>> Jon >> > >> >>>>>>>> >> > >> >>>>>>>> On Wed, Jul 5, 2017 at 9:25 AM, Romain Manni-Bucau < >> > >> >>>>>> rmannibu...@gmail.com> >> > >> >>>>>>>> wrote: >> > >> >>>>>>>> >> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu < >> > >> gurkanerdo...@yahoo.com >> > >> >> . >> > >> >>>>>>>>> invalid>: >> > >> >>>>>>>>> >> > >> >>>>>>>>>> Romain>>>>@Gurkan: concretely nothing changed factually >> since >> > >> we >> > >> >>>>>>>>> discussed >> > >> >>>>>>>>>> it and concluded we can't pay the overhead at the moment >> so >> > why >> > >> >>>>>> pushing >> > >> >>>>>>>>>> it?I looked at the commit history from github ( >> > >> >>>>>>>>> https://github.com/apache/ >> > >> >>>>>>>>>> tomee/graphs/contributors). Only some couple of members >> > provide >> > >> >>>>>>>>>> contributions in last couple of years. We need a more >> > >> >> stable/healthy >> > >> >>>>>>>>>> community to increase the chance of long living the >> project. >> > >> You >> > >> >> are >> > >> >>>>>>>>> wrong, >> > >> >>>>>>>>>> the reason behind the such discussion is not related with >> > prod, >> > >> >>>>>> website >> > >> >>>>>>>>> or >> > >> >>>>>>>>>> project source code. We are looking for some alternative >> > >> solution >> > >> >>>>> (at >> > >> >>>>>>>>> least >> > >> >>>>>>>>>> temporarily) because of the mentioned problems. I suspect >> > that >> > >> >> this >> > >> >>>>>>>> type >> > >> >>>>>>>>> of >> > >> >>>>>>>>>> conflicts may occur in the future again. I am pushing this >> > for >> > >> the >> > >> >>>>>>>>> success >> > >> >>>>>>>>>> and future of Apache TomEE. I am not a PMC member or >> > committer >> > >> of >> > >> >>>>>> TomEE >> > >> >>>>>>>>>> project, but I just wanted to give my comments as ASF >> member. >> > >> >>>>>>>>>> >> > >> >>>>>>>>> >> > >> >>>>>>>>> Don't think so Gurkan, the problem was really bound to end >> > user >> > >> >>>>> direct >> > >> >>>>>>>>> impact and we tackled it with the personal html area usage >> we >> > >> need >> > >> >> to >> > >> >>>>>>>>> document now. >> > >> >>>>>>>>> >> > >> >>>>>>>>> >> > >> >>>>>>>>>> Regards.Gurkan- >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain >> > >> Manni-Bucau >> > >> >> < >> > >> >>>>>>>>>> rmannibu...@gmail.com> wrote: >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> @Gurkan: concretely nothing changed factually since we >> > >> discussed >> > >> >> it >> > >> >>>>>> and >> > >> >>>>>>>>>> concluded we can't pay the overhead at the moment so why >> > >> pushing >> > >> >> it? >> > >> >>>>>>>>>> Concretely the issue was very particular in term of >> process >> > >> cause >> > >> >>>>>>>>> affecting >> > >> >>>>>>>>>> almost directly our "prod" versus our project source >> doesn't >> > >> and >> > >> >> we >> > >> >>>>>> can >> > >> >>>>>>>>>> therefore tolerate more latency. And side note (probably >> some >> > >> >>>>> wording >> > >> >>>>>>>>> issue >> > >> >>>>>>>>>> but just to make it obvious if not): if it is to go back >> to >> > the >> > >> >>>>> normal >> > >> >>>>>>>>>> process anyway after then we can gain these 3 months and >> > >> already >> > >> >>>>> work >> > >> >>>>>>>> as >> > >> >>>>>>>>> we >> > >> >>>>>>>>>> and we'll do ;). >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> Romain Manni-Bucau >> > >> >>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > >> >>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > >> >>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >> > >> https://github.com/ >> > >> >>>>>>>>>> rmannibucau> | >> > >> >>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | >> JavaEE >> > >> >> Factory >> > >> >>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> 2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu < >> > >> gurkanerdo...@yahoo.com >> > >> >> . >> > >> >>>>>>>>>> invalid>: >> > >> >>>>>>>>>> >> > >> >>>>>>>>>>> Hi MarkThis is only for fixing the appeared (very >> important) >> > >> >>>>> problem >> > >> >>>>>>>> in >> > >> >>>>>>>>>>> the community. So, I don't see what will happen to the >> > project >> > >> >> in 3 >> > >> >>>>>>>>>> months >> > >> >>>>>>>>>>> period with RTC process? So, at least 3 months, every >> commit >> > >> will >> > >> >>>>> be >> > >> >>>>>>>>>>> approved by the community via consensus. After that, we >> can >> > >> >> safely >> > >> >>>>>>>>> return >> > >> >>>>>>>>>>> back to the normal process. >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Thanks.Gurkan >> > >> >>>>>>>>>>> On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark >> Struberg >> > >> >>>>>>>>>>> <strub...@yahoo.de.INVALID> wrote: >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> RTC in my experience _only_ works on release branches, >> but >> > is >> > >> a >> > >> >>>>> total >> > >> >>>>>>>>>>> community killer on the mainstream branch (master, dev, >> > >> whatever >> > >> >>>>> you >> > >> >>>>>>>>> call >> > >> >>>>>>>>>>> it). >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> We usually don't have so many concurrent commits on the >> same >> > >> >> topic. >> > >> >>>>>>>>> There >> > >> >>>>>>>>>>> was recently an exceptional case and it got resolved. >> > >> >>>>>>>>>>> Thus -1 >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Of course discussions might be done first. But not via PR >> > but >> > >> via >> > >> >>>>>>>> mail. >> > >> >>>>>>>>>>> Usually the devs have a good feeling about what is >> sensible >> > >> and >> > >> >>>>> what >> > >> >>>>>>>>> not. >> > >> >>>>>>>>>>> For some deep change one usually sends a patch first for >> > >> review. >> > >> >>>>> That >> > >> >>>>>>>>> is >> > >> >>>>>>>>>>> nothing we need to enforce - every good programmer will >> do >> > >> just >> > >> >>>>> that! >> > >> >>>>>>>>>>> Otoh there are 99.99% of stuff which you just get done >> and >> > >> commit >> > >> >>>>> it. >> > >> >>>>>>>>> And >> > >> >>>>>>>>>>> if there is something fishy, then it get's caught via the >> > >> commit >> > >> >>>>> log >> > >> >>>>>>>>>> mails >> > >> >>>>>>>>>>> anyway. >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> LieGrue, >> > >> >>>>>>>>>>> strub >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>>> Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore < >> > >> >>>>>>>>>>> jonathan.gallim...@gmail.com>: >> > >> >>>>>>>>>>>> >> > >> >>>>>>>>>>>> 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 >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>> >> > >> >>>>>>>> >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> -- >> > >> >>>> Andy Gumbrecht >> > >> >>>> https://twitter.com/AndyGeeDe >> > >> >>>> http://www.tomitribe.com >> > >> >>> >> > >> >> >> > >> >> >> > >> > >> > >> > >> > >> > -- >> > >> > Andy Gumbrecht >> > >> > https://twitter.com/AndyGeeDe >> > >> > http://www.tomitribe.com >> > >> >> > >> >> > > >> > > >> > > -- >> > > Andy Gumbrecht >> > > https://twitter.com/AndyGeeDe >> > > http://www.tomitribe.com >> > > >> > >> > >> > >> > -- >> > Andy Gumbrecht >> > https://twitter.com/AndyGeeDe >> > http://www.tomitribe.com >> > >> > > > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
