That's *not* how a consensus vote works. An RTC commit does not need a majority at all - That would be a 'Majority Approval', and of course *that* is not any use at all for RTC.
No one here is suggesting it that way, and it would be stupid to make anyone wait 72h for a simple review. It is not stupid to say create a PR and have someone else review it - That's the workflow on just about every community git project out there - Don't merge your own PR is a really common process. If David comes on 9 hrs later and doesn't like it then he'd need to submit a counter PR, and that would also need 3+1. That's the whole point. It's about teamwork and eyes on by more than just one person, not about making it impossible to work. If you do a PR and JL *and* Romain ack it then where is the issue with that? You're seeing it, or making it sound, way more complicated than it is. Right now there is *no* consensus. Right now anyone can commit at any time without eyes on by anyone else. Right now if David doesn't like it 9 hours later, then he can just *trash* it as he sees fit. So, a 3+1 commit with no time frame makes a lot of sense imo. It's little more than a PR with peer review. Andy. On 8 July 2017 at 00:17, Mark Struberg <strub...@yahoo.de.invalid> wrote: > Just for sake of clarifying the procedural stuff. A consensus vote > requires that the majority of PMC members did vote. > Consider I commit something and ping lt's say JL and Romain via IRC to ack > it. They send their +1 in the frame 1 minute after my PR. Then I go on and > push it. Now 9 hours later David awakes over in US and he doesn't like it. > He might vote -1, but it's already committed. Not what's intended, isn't? > > A VOTE without any time frame or a quorum does make little sense imo. > > LieGrue, > strub > > > Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <agumbre...@tomitribe.com > >: > > > > 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
