I feel like not getting code reviews is often a symptom of some other fundamental issue with how change is introduced to a community.
When I joined the Aurora team at Twitter there were some principals in place for getting your changes accepted to the community and I still feel like when you follow them, getting code reviews rarely requires more than a gentle ping. Maybe none of these have been formally communicated or shared externally, but some of the principals I've picked up include: * Introduce problems before solutions. * Get buy-in that this is a problem worth solving. * Work towards abstractions that work for the community and not just for your specific use case. * Solicit early feedback on potential solutions. * Get explicit buy-in for the solution (these +1s would be the people you add to the reviewers list later). This usually means writing a Design Doc. * Plan your work carefully to avoid the dreaded code dumps (where possible). For large efforts work towards multiple, small patches that are easy to review. * Follow-up on review feedback quickly to avoid demanding expensive paging and context-switches from your reviewers later. * Build trust by thinking through production rollout and rollback scenarios. There is obviously more than just this list, but a lot of the patches that struggle to get reviews (or get hard -1s after a bunch of work is done) fail on one (or more) of these fundamental ideas. It's also worth calling out that having informal discussions on Slack is fine, but should also be done on the dev lists, and ideally in the form of a written document. This is the best way to include those of who feel like Slack is a massive productivity drain :) I guess this is my long-winded way of saying that I'm a -1 on moving to lazy consensus. I wonder if a lot of the concerns can be solved by just improving communication? Maybe we can revive the weekly developer meeting that we used to run in IRC. On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote: > Thanks for your input Stephan, very much appreciated! Replies inline: > > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <stephan....@blue-yonder.com > > > wrote: > > > Hey Renan, > > > > thanks again for bringing this up. In my experience, the pain comes from > > building, testing & voting rather the packaging scripts themselves. I > > therefore think we should discontinue building, but continue to maintain > > the scripts so that users can build them on their own when necessary. > > > > Fully agree on this. I will even go as far as making unofficial builds > available for the time being if no one is opposed and if it's not against > Apache policy to do so. > > > > > We must be careful though with linking the ‘nightly jenkins builds’ on > the > > website. We got called out for this once in the past and had to take the > > link down. > > > > Noted, thanks for bringing this up! > > > > > We also see a lack of involvement in code reviews. I think we should > > consider setting up a more formal lazy consensus policy > > https://www.apache.org/foundation/voting.html#LazyConsensus : For > > example, patches maybe merged even with a single ‘ship it’ from a > > committer, if there is neither a ship-it nor a veto from other committers > > within 7 days. > > > > I think this is a very valid way forward at this point. How does everyone > else feel about this? > > > > > Best regards, > > Stephan > > > > > -Renan > > > > > From: Santhosh Kumar Shanmugham <sshanmug...@twitter.com> > > Reply-To: "u...@aurora.apache.org" <u...@aurora.apache.org> > > Date: Thursday, 17. May 2018 at 22:13 > > To: "dev@aurora.apache.org" <dev@aurora.apache.org> > > Cc: "u...@aurora.apache.org" <u...@aurora.apache.org> > > Subject: Re: [DISCUSS] State of the Community > > > > Hello Renan, > > > > I understand your frustration. > > > > I am a strong +1 for automating the release and voting process. I > performed > > a release a while back and the process definitely needs it improve > > documentation > > at the least. If one of the members who are more familiar with this > > process can > > create a backlog, I will be happy to chip in. > > > > -Santhosh > > > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org > <mailto: > > re...@apache.org>> wrote: > > All, > > > > Discussion has been open for 13 days and only one user has chimed in. > > Unfortunately it looks like talking point number one will be a serious > > concern going forward. I will give until tomorrow 12 PM San Francisco > time > > for folks to voice their opinion on these issues. > > > > After tomorrow I will call a vote to cease distributions of official > binary > > packages from versions 0.21.0 onwards until the process is automated and > > voting for the voting for the binary packages can be combined with the > > tar.gz release. > > > > Since no feedback was received regarding talking point three, the idea > will > > be dropped. > > > > -Renan > > > > > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelva...@gmail.com > < > > mailto:renanidelva...@gmail.com>> > > wrote: > > > > > In some ways, that's some of the best feedback we can get. Very happy > to > > > hear that Aurora is working fo well for Chartbeat. > > > > > > I do hope that you guys find some time to help us maintain the project. > > > Every little bit counts! > > > > > > -Renan > > > > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <r...@chartbeat.com > <mailto: > > r...@chartbeat.com>> wrote: > > > > > >> As strong users of aurora but weak contributors, we at Chartbeat > > >> apologize for our lack of participation. We’re several versions behind > > on > > >> mesos/aurora upgrades and that’s honestly because it works for us :) > > >> > > >> Going forward we’re hoping to be able to participate more, at least > with > > >> testing new releases. > > >> > > >> We thank you though! > > >> > > >> Rick and the rest of Chartbeat Engineering > > >> > > >> > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org > <mailto: > > re...@apache.org>> wrote: > > >> > > > >> > Hello all, > > >> > > > >> > I wanted to bring up a few points for discussion with the community. > > I'd > > >> > really like to hear what the community's thoughts are on these > issues > > >> and > > >> > how can resolve them. > > >> > > > >> > 1. Lack of participation. This is due to many members moving on from > > the > > >> > project and becoming dormant. More concerning is the fact that our > PMC > > >> > roster sits at 21 members [1] of which fewer than half have > > >> participated in > > >> > the project during the last 6 months. > > >> > > > >> > This inactivity has led the voting process for releases to be held > up > > by > > >> > the inability to reach the required minimum 3 votes for releases > (both > > >> > tar.gz and binary). Our latest binary packaging vote has been going > on > > >> for > > >> > more than a month. [2] > > >> > > > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly > > to > > >> the > > >> > Aurora PMC, we hope to mitigate this issue. > > >> > > > >> > It would be fantastic to see some initiative from long contributing > > >> members > > >> > to make a case for themselves for being considered for committer > > and/or > > >> PMC > > >> > membership. > > >> > > > >> > 2. Binary packages. While we have been struggling to get enough > votes > > >> for > > >> > making the release official, the voting process has been marked by a > > >> lack > > >> > of enthusiasm from the community. > > >> > > > >> > I know that many folks are using these packages (including myself), > > but > > >> we > > >> > need to hear feedback when we call votes. It is not enough to stand > by > > >> > silently if everything works; please let us know about it. > > >> > > > >> > As it stands, the enthusiasm (or lack thereof) for binary packages > > >> doesn't > > >> > justify the overhead involved in releasing them. Therefore I propose > > >> that > > >> > we drop official binary packages for the next release. This is up > for > > >> > discussion and I'd love to hear everyone's opinion on this. > > >> > > > >> > An alternative to ending binary packages would be to automate the > > >> process > > >> > on tar.gz releases, but that would most likely need to be a > community > > >> > contribution. > > >> > > > >> > 3. Version 1.0. I realize this is a touchy subject. While other > > projects > > >> > that were started around the same time as Aurora, such as Mesos > > itself, > > >> > have gone on to make a 1.0 release (indicating the projects > maturity), > > >> we > > >> > have stuck to our 0.X.0 releases. > > >> > > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but > I > > >> > wanted to bring up for discussion how everyone felt about making our > > >> next > > >> > release a 1.0 release to reflect the stability and maturity of the > > >> project. > > >> > > > >> > That is all from me, if anyone else has any other concerns regarding > > the > > >> > Aurora community, feel free to bring it up in this thread! > > >> > > > >> > -Renan > > >> > > > >> > > > >> > [1] https://projects.apache.org/committee.html?aurora > > >> > [2] https://lists.apache.org/thread.html/ > > 9df9d142408efffd11a1cdc5e4c1e3 > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http:// > > 3Cdev.aurora.apache.org>%3E > > >> > > >> > > > > > > > >
