I would love to see roadmaps, potential new features that would bring fresh energy and excitement rather than a maintenance project kind of feel. I think this project brings a lot that more hyped projects do not but stagnation can hurt.
Thx > On May 22, 2018, at 4:18 PM, Santhosh Kumar Shanmugham > <sshanmug...@twitter.com> wrote: > > I would like to see this community become active again. If we can fix the > gaps > with processes that David explained above, I am sure we can revive the > community. > > As for the timely reviews, I have a couple of requests: > - Triage - find appropriate reviewers for each patch to assign ownership > - Expectations - work with the author to set meaningful timelines for review > round-trips > > -Santhosh > >> On Tue, May 22, 2018 at 2:26 PM, Renan DelValle <renanidelva...@gmail.com> >> wrote: >> 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: "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 >> > > > >> >> > > > >> >> > > > > >> > > > >> > > > >> > > >> > >
