Things that help: - Be persistent. People are busy, so just ping them if there’s been no response for a couple of weeks. Hopefully, as the project continues to develop, this will become less necessary. - Only ping reviewers after test results are back from Jenkins. Make sure all the tests are clear before reaching out, unless you need help understanding why a test is failing. - Whenever possible, keep PRs small, small, small. - Get buy-in on the dev list before working on something, especially larger features, to make sure you are making something that people understand and that is in accordance with Spark’s design.
I’m just speaking as a random contributor here, so don’t take this advice as gospel. Nick On Mon Dec 08 2014 at 3:08:02 PM Ganelin, Ilya <ilya.gane...@capitalone.com> wrote: > Thank you for pointing this out, Nick. I know that for myself and my > colleague who are starting to contribute to Spark, it¹s definitely > discouraging to have fixes sitting in the pipeline. Could you recommend > any other ways that we can facilitate getting these PRs accepted? Clean, > well-tested code is an obvious one but I¹d like to know if there are some > non-obvious things we (as contributors) could do to make the committers¹ > lives easier? Thanks! > > -Ilya > > On 12/8/14, 11:58 AM, "Nicholas Chammas" <nicholas.cham...@gmail.com> > wrote: > > >I recently came across this blog post, which reminded me of this thread. > > > >How to Discourage Open Source Contributions > ><http://danluu.com/discourage-oss/> > > > >We are currently at 320+ open PRs, many of which haven't been updated in > >over a month. We have quite a few PRs that haven't been touched in 3-5 > >months. > > > >*If you have the time and interest, please hop on over to the Spark PR > >Dashboard <https://spark-prs.appspot.com/>, sort the PRs by > >least-recently-updated, and update them where you can.* > > > >I share the blog author's opinion that letting PRs go stale discourages > >contributions, especially from first-time contributors, and especially > >more > >so when the PR author is waiting on feedback from a committer or > >contributor. > > > >I've been thinking about simple ways to make it easier for all of us to > >chip in on controlling stale PRs in an incremental way. For starters, > >would > >it help if an automated email went out to the dev list once a week that a) > >reported the number of stale PRs, and b) directly linked to the 5 least > >recently updated PRs? > > > >Nick > > > >On Sat Aug 30 2014 at 3:41:39 AM Nicholas Chammas < > >nicholas.cham...@gmail.com> wrote: > > > >> On Tue, Aug 26, 2014 at 2:02 AM, Patrick Wendell <pwend...@gmail.com> > >> wrote: > >> > >>> it's actually precedurally difficult for us to close pull requests > >> > >> > >> Just an FYI: Seems like the GitHub-sanctioned work-around to having > >> issues-only permissions is to have a second, issues-only repository > >> <https://help.github.com/articles/issues-only-access-permissions>. Not > a > >> very attractive work-around... > >> > >> Nick > >> > > ________________________________________________________ > > The information contained in this e-mail is confidential and/or > proprietary to Capital One and/or its affiliates. The information > transmitted herewith is intended only for use by the individual or entity > to which it is addressed. If the reader of this message is not the > intended recipient, you are hereby notified that any review, > retransmission, dissemination, distribution, copying or other use of, or > taking of any action in reliance upon this information is strictly > prohibited. If you have received this communication in error, please > contact the sender and delete the material from your computer. > >
