Thanks for the feedback David! On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dmclaugh...@apache.org> wrote:
> 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. > All good points and I think those of us that have been here long enough do strive to follow these principles. For what it's worth, I've always really appreciated the feedback from the folks running at scale when it comes to my contributions. It shows they care about the project and pushes me to write better code. That said, since these are mostly unwritten rules, either we need to write them down or we need to cope with the fact that some folks may not follow them. What would really be unfortunate is to lose potential contributors because they get discouraged after submitting a patch and running into this "invisible" red tape. I can already see this happening such as in https://reviews.apache.org/r/66490/ There may not be a solution to that problem (and may be a different problem altogether) but it would at least be nice to have an outline of what procedure is expected from potential contributors. Another thing I'd like to bring up is that our use of JIRA has drastically decreased. There is very little activity going on there. That used to be the starting point of discussion for any contribution. As engagement has dropped, that's pretty much gone away leaving us without much defense in shutting down an idea before it's coded. > > 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. > I agree on this point but what concerns me more than the -1's is the lack of engagement. For example https://reviews.apache.org/r/66537/ If we want to engage the community, we gotta give feedback, good or bad. For me, letting review requests rot is one sure fire indicator to potential contributors that sending a contribution is not worth their time or effort (and our process is pretty time consuming given the outline we tend to follow above). We should find a way to keep the core tenets outlined above while streamlining the process. Maybe move away from reviewboard into gitbox so we can do code reviews on github? Not sure if this would help at all, but it may since folks are more familiar with that workflow so it brings down a barrier for contribution. (Side note: maybe it's a good time to propose a cleanup in reviewboard. Right now our group page on reviewboard looks like a graveyard. In my opinion, anything older than a year isn't likely to be committed and should therefore be discarded. I can put this to a vote if the general consensus is positive towards this idea.) > 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 :) Noted, though I will say our slack channel doesn't have much of a pulse these days either (and hasn't for quite some time). > > 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. > This would be great but sadly I just don't see the engagement we need to be able to pull this off. We could not even get enough interest to host an Aurora Meetup, so I see this as an uphill battle if we attempt it. I could be wrong though and I would be more than happy to be part of it if we start running it. -Renan > > > 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: "user@aurora.apache.org" <user@aurora.apache.org> > > > Date: Thursday, 17. May 2018 at 22:13 > > > To: "d...@aurora.apache.org" <d...@aurora.apache.org> > > > Cc: "user@aurora.apache.org" <user@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 > > > >> > > > >> > > > > > > > > > > > > >
