Hi guys, Thanks for bringing up the issues regarding getting patches/reviews committed. Instead of answering specific questions or points raised in this thread, I wanted to highlight some of the things we've done or doing (and plan to do) to improve the process further.
*Re: Roadmap*: Perhaps this is not communicated as prominently as it should've been, but we do have a roadmap doc (that will be reviewed/updated during community syncs) on the wiki <https://cwiki.apache.org/confluence/display/MESOS/%5BDRAFT%5D+Roadmap>. I'll make sure to update the website to link to the roadmap so people can find it more easily. The roadmap captures the current priorities of the project and where most shepherds time is being spent on. There is nothing opaque about this. If you are newbie to the project, it would be best to pick work from the roadmap items instead of something random. If you do so, there is a very high chance that the shepherd of the roadmap item will be able to shepherd your patch through. This is mainly because shepherds have limited bandwidth to do reviews and working on something that they are already shepherding will need fewer context switches for them. I've personally had success in steering new contributors to work on items I'm already shepherding. *Re: Triaging tickets/reviews: *One of the biggest pain points I've observed (which was also pointed out in this thread) is that contributors sometimes do not even get feedback on their patches. As a community and PMC, we need to figure out how to improve this. From Mesosphere side, we've begin instituting some processes to help alleviate some of this. I do urge committers that work for other companies to also chip in here. *Re: Reviews: *Every person in the community should feel empowered to review each other's patches if they feel have the context and knowledge. I think shepherds will be thankful if contributors get reviews from non-committers to suss out the low hanging fruit (typos, style etc). The "credit" for doing so would be that you would be eventually recognized and nominated to be a committer. *Re: Committers: *I think it is clear that we need to add more committers and groom them to be shepherds to better balance the reviewing workload. The good news is that we have a few folks already in the pipeline that we feel are ready to be committers! We will be nominating and voting them in the next couple weeks. *Re: Metrics: *While there is a visible section of the community that is frustrated I believe we've improved (and continue to improve) the reviewing process over time. We plan to gather and share metrics about how we are doing in a continuous fashion (community syncs?) going forward. Finally, I would like to point out that this is a team and community effort. No one company or organization is ultimately directly responsible. In addition to recognizing and pointing problems, I would love for us to come up with solutions. And by us, I mean everyone in the community, not just the PMC. We will discuss some of these in our next community sync (this thursday, 3 PM PST!), so please join. Thanks, On Mon, May 16, 2016 at 11:01 AM, Cong Wang <[email protected]> wrote: > Hello, Alex > > On Mon, May 16, 2016 at 10:17 AM, Alex Rukletsov <[email protected]> > wrote: > > Cong, > > > > it's strange that you project your frustrations—which are understandable > > and may have good reasons—on the project as a whole. There are reasons > why > > things are done in the way they are done; our primary goal is quality, > we'd > > rather have a few well implemented features rather than a bunch of > > half-finished efforts that are hard to maintain. This means sometimes we > > can't distract and invest time into some great but not yet prioritized > > features. > > Sure, no one asks you to accept everything proposed, you always have > the right to decline code you don't like, and this is clearly not what I am > complaining. > > What I keep complaining is how fast you response to a review > (no matter accept or decline), no one will be happy when his/her > patch got no response after several months. > > And this is still happening in your community right now: > > https://reviews.apache.org/r/45605/ > https://reviews.apache.org/r/45606/ > https://reviews.apache.org/r/45607/ > https://reviews.apache.org/r/41302/ > https://reviews.apache.org/r/41305/ > https://reviews.apache.org/r/41306/ > https://reviews.apache.org/r/41308/ > > (I can show you more as long as you need.) > > I am sure you will say I need to ping someone, clearly this doesn't work. > > > > > You brought up some reasonable suggestions in other threads. As every > group > > of people with more that 1 person, Mesos community has some inertia. > > Features, ideas, and processes should settle down and cook for a while > > (except if it is a critical bug). It would be great if we can work > together > > improving developer experience, despite frustrations, inertia, and > personal > > opinions. > > I am glad to help, but people don't need my help. > > What progress do you make so far? Is there any new committer joining? > Is there any non-working committers kicked out? Does any of you committers > work more efficiently that before? > > > > > > But everyone can easily help us to deal with the known issues. Reviewing > > patches of other contributors, paying attention to style and typos, do > > better testing. All these things can be done right now, without > discussion > > and involving committers and will directly help them (committers) to feel > > more comfortable about the feature and land patches. For example, you > could > > have reviewed r/47281/ and help José, right? > > > Come on, even if I helped to review, so what? It is still there waiting for > committers. Most of the times, committers are the bottleneck, not > reviewers. > > On the other hand, what can I get if I help to review a patch? Will my name > be shown in the git log? No. Will I get any real credit? No. So, why > should I help to review? ;-P > > > > > It would also help if we separate technical discussions from operational > > issues. This way it's easier to search history. > > > > This is all about your development process, not operations. > > > > Though k8s is a great project, I don't think that hopping from project to > > project is a rewarding experience. Like in a relationship, sometimes one > > should invest time and effort to make things work. And be patient and > > forgiving : ). > > > > Sounds like you give yourself a reason to let people to wait for 6 months > for their code to commit... Oh, well, I have been there: > > https://reviews.apache.org/r/38117/ >
