You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Nicholas Chammas <ni...@gmail.com> on 2014/12/08 20:58:08 UTC
Re: Handling stale PRs
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 <pw...@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
>
Re: Handling stale PRs
Posted by Nicholas Chammas <ni...@gmail.com>.
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 <Il...@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" <ni...@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 <pw...@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.
>
>
Re: Handling stale PRs
Posted by "Ganelin, Ilya" <Il...@capitalone.com>.
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" <ni...@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 <pw...@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
Re: Handling stale PRs
Posted by Nicholas Chammas <ni...@gmail.com>.
Shout-out to Michael and other Spark SQL contributors for really trimming
down the number of open/stale Spark SQL PRs
<https://spark-prs.appspot.com/#sql>.
As of right now, the least recently updated open Spark SQL PR goes back
only 11 days.
Nice work!
Nick
On Mon Dec 08 2014 at 2:58:08 PM 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 <pw...@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
>>
>