spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ganelin, Ilya" <Ilya.Gane...@capitalone.com>
Subject Re: Handling stale PRs
Date Mon, 08 Dec 2014 20:07:59 GMT
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.chammas@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.chammas@gmail.com> wrote:
>
>> On Tue, Aug 26, 2014 at 2:02 AM, Patrick Wendell <pwendell@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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org


Mime
View raw message