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
