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 > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > >
