Re: Auto-cleaning up Stale PRs

[Liang Chen]

+1.

Apache CarbonData will try it to clean invalid pull requests and jira
issues, thanks.

Regards
Liang




--
Sent from: http://apache-incubator-general.996316.n3.nabble.com/

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Auto-cleaning up Stale PRs

[Sid Anand]

Will do.

-s

On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher  wrote:

> Hi -
>
> No objections from me. I do ask you let the IPMC know in your podling
> report if this results in any controversy from the creators of any
> autoclosed pull requests.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Sep 19, 2018, at 6:48 PM, Sid Anand  wrote:
> >
> > Thanks Greg and Ismael!
> > -s
> >
> >> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein  wrote:
> >>
> >> Hello all,
> >>
> >> The confusion here was "write access to the repository" (not allowed)
> >> versus "write access to Pull Requests" (allowed). It took the Beam folks
> >> some research to determine that GitHub *does* differentiate between
> these
> >> two write capabilities (historically, GitHub has not been very granular
> >> with permissions).
> >>
> >> So. When Airflow said Probot Stale needed write access, we took that to
> >> mean *code*.
> >>
> >> After the pointer to Beam, reminding Infra of the research Beam had done
> >> (and my enabling of Stale for them) ... we realized that Stale *is*
> >> perfectly fine because it doesn't touch the code repository.
> >>
> >> Probot Stale has been enabled for Airflow.
> >>
> >> Cheers,
> >> Greg Stein
> >> Infrastructure Administrator, ASF
> >>
> >>
> >>> On Wed, Sep 19, 2018 at 7:47 PM Sid Anand  wrote:
> >>>
> >>> Ismael,
> >>> Thanks for this pointer. I've re-opened my INFRA ticket and referenced
> >> your
> >>> Apache Beam one. Super helpful.. if we get it enabled, please collect a
> >>> beer from anyone in the Apache Airflow community!
> >>>
> >>> -s
> >>>
>  On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía 
> wrote:
> 
>  While I agree that autoclosing PRs can be unwelcoming. I don't see
>  clearly the argument of INFRA in the ticket.
> 
> > The policy of no-write-access for bots is a requirement by the
>  foundation legal team. We cannot allow write access to repos without
> an
>  ICLA.
> 
>  Labeling and closing the PR in github does not imply write-access from
>  the bot into the 'real' gitbox repository, so I don't see how this can
>  be an issue, or are we in a gray area (in case bot automation of
>  metadata can have legal issues which I doubt since this is not part of
>  the source distribution).
> 
>  As a precedent we had Probot/Stale enabled for Apache Beam so I
>  suppose that this should be possible for Airflow too.
>  https://issues.apache.org/jira/browse/INFRA-16589
> 
> > On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
> >
> > Apache Airflow has, at any point, >200 PRs open. During the slower
> >>> summer
> > months, we've been merging 100-200 PRs a month. We have been growing
> >>> the
> > community -- we have <600 contributors, ~200 companies using it, and
> >>> 20+
> > committers. A person is promoted to "Committer" in recognition for
> >> work
> > he/she has done without an expectation of future work in maintaining
> >>> the
> > code base. Hence, minting new committers doesn't always translate
> >> into
> > greater bench strength where merging PRs is concerned. That said, we
> >>> are
> > actively adding new committers. The last 4-5 committers we added have
>  been
> > super active maintainers, so the coverage on PRs and questions has
> >> been
> > getting better.
> >
> > There are many causes of Cold-case PRs:
> >
> >   1. Submitter is not actively responding
> >  1. One example is that we requested tests and they were never
>  written
> >  2. Discussion ensued on the PR and the submitter did not accept
> >>> the
> >  community's feedback
> >   2. Committers didn't get to it in a timely manner and after a
> >> while
>  the
> >   engagement fell
> >
> > We are in a better position now to handle (2) -- this was not the
> >> case
> >>> a
> > year ago. We're at least able to keep up with our in-flow of PRs
> > week-to-week, but are still having challenges with the
> > previously-established backlog. But, (1) is also a contributor to
> >> stale
>  PRs.
> >
> > We do have a lot of stale PRs to manually handle -- I spent all of
> >>> Summer
> > 2017 pinging submitters of old PRs and I find myself in the same
> >>> position
> > now.
> >
> > Probot/stale is a useful tool. It has legitimate use-cases. A policy
> > reflects the health/mentality/approaches of the community. A tool
> >> like
>  this
> > enforces the policy. Let's not overlook adoption of what would be a
> >>> very
> > useful tool to the community due to a meta conversation about
> >> policy. I
> > think everyone on this list cares about growing a healthy and vibrant
> > community. We also care about being efficient with our spare time.
> >>> This
> > tools can help us manage both.
> >
> > Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs
> >>> need
>  

Re: Auto-cleaning up Stale PRs

[Dave Fisher]

Hi -

No objections from me. I do ask you let the IPMC know in your podling report if 
this results in any controversy from the creators of any autoclosed pull 
requests.

Regards,
Dave

Sent from my iPhone

> On Sep 19, 2018, at 6:48 PM, Sid Anand  wrote:
> 
> Thanks Greg and Ismael!
> -s
> 
>> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein  wrote:
>> 
>> Hello all,
>> 
>> The confusion here was "write access to the repository" (not allowed)
>> versus "write access to Pull Requests" (allowed). It took the Beam folks
>> some research to determine that GitHub *does* differentiate between these
>> two write capabilities (historically, GitHub has not been very granular
>> with permissions).
>> 
>> So. When Airflow said Probot Stale needed write access, we took that to
>> mean *code*.
>> 
>> After the pointer to Beam, reminding Infra of the research Beam had done
>> (and my enabling of Stale for them) ... we realized that Stale *is*
>> perfectly fine because it doesn't touch the code repository.
>> 
>> Probot Stale has been enabled for Airflow.
>> 
>> Cheers,
>> Greg Stein
>> Infrastructure Administrator, ASF
>> 
>> 
>>> On Wed, Sep 19, 2018 at 7:47 PM Sid Anand  wrote:
>>> 
>>> Ismael,
>>> Thanks for this pointer. I've re-opened my INFRA ticket and referenced
>> your
>>> Apache Beam one. Super helpful.. if we get it enabled, please collect a
>>> beer from anyone in the Apache Airflow community!
>>> 
>>> -s
>>> 
 On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía  wrote:
 
 While I agree that autoclosing PRs can be unwelcoming. I don't see
 clearly the argument of INFRA in the ticket.
 
> The policy of no-write-access for bots is a requirement by the
 foundation legal team. We cannot allow write access to repos without an
 ICLA.
 
 Labeling and closing the PR in github does not imply write-access from
 the bot into the 'real' gitbox repository, so I don't see how this can
 be an issue, or are we in a gray area (in case bot automation of
 metadata can have legal issues which I doubt since this is not part of
 the source distribution).
 
 As a precedent we had Probot/Stale enabled for Apache Beam so I
 suppose that this should be possible for Airflow too.
 https://issues.apache.org/jira/browse/INFRA-16589
 
> On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
> 
> Apache Airflow has, at any point, >200 PRs open. During the slower
>>> summer
> months, we've been merging 100-200 PRs a month. We have been growing
>>> the
> community -- we have <600 contributors, ~200 companies using it, and
>>> 20+
> committers. A person is promoted to "Committer" in recognition for
>> work
> he/she has done without an expectation of future work in maintaining
>>> the
> code base. Hence, minting new committers doesn't always translate
>> into
> greater bench strength where merging PRs is concerned. That said, we
>>> are
> actively adding new committers. The last 4-5 committers we added have
 been
> super active maintainers, so the coverage on PRs and questions has
>> been
> getting better.
> 
> There are many causes of Cold-case PRs:
> 
>   1. Submitter is not actively responding
>  1. One example is that we requested tests and they were never
 written
>  2. Discussion ensued on the PR and the submitter did not accept
>>> the
>  community's feedback
>   2. Committers didn't get to it in a timely manner and after a
>> while
 the
>   engagement fell
> 
> We are in a better position now to handle (2) -- this was not the
>> case
>>> a
> year ago. We're at least able to keep up with our in-flow of PRs
> week-to-week, but are still having challenges with the
> previously-established backlog. But, (1) is also a contributor to
>> stale
 PRs.
> 
> We do have a lot of stale PRs to manually handle -- I spent all of
>>> Summer
> 2017 pinging submitters of old PRs and I find myself in the same
>>> position
> now.
> 
> Probot/stale is a useful tool. It has legitimate use-cases. A policy
> reflects the health/mentality/approaches of the community. A tool
>> like
 this
> enforces the policy. Let's not overlook adoption of what would be a
>>> very
> useful tool to the community due to a meta conversation about
>> policy. I
> think everyone on this list cares about growing a healthy and vibrant
> community. We also care about being efficient with our spare time.
>>> This
> tools can help us manage both.
> 
> Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs
>>> need
 to
> be kept open so we don't lose visibility of bugs/features/etc... This
 tool
> doesn't handle JIRA closing anyway.
> 
> -s
> 
> On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas 
>> wrote:
> 
>>> On 12/09/18 19:16, Sid Anand wrote:
>>> A stale PR is defined by a policy -- 

Re: Auto-cleaning up Stale PRs

[Sid Anand]

Thanks Greg and Ismael!
-s

On Wed, Sep 19, 2018 at 6:39 PM Greg Stein  wrote:

> Hello all,
>
> The confusion here was "write access to the repository" (not allowed)
> versus "write access to Pull Requests" (allowed). It took the Beam folks
> some research to determine that GitHub *does* differentiate between these
> two write capabilities (historically, GitHub has not been very granular
> with permissions).
>
> So. When Airflow said Probot Stale needed write access, we took that to
> mean *code*.
>
> After the pointer to Beam, reminding Infra of the research Beam had done
> (and my enabling of Stale for them) ... we realized that Stale *is*
> perfectly fine because it doesn't touch the code repository.
>
> Probot Stale has been enabled for Airflow.
>
> Cheers,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
> On Wed, Sep 19, 2018 at 7:47 PM Sid Anand  wrote:
>
> > Ismael,
> > Thanks for this pointer. I've re-opened my INFRA ticket and referenced
> your
> > Apache Beam one. Super helpful.. if we get it enabled, please collect a
> > beer from anyone in the Apache Airflow community!
> >
> > -s
> >
> > On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía  wrote:
> >
> > > While I agree that autoclosing PRs can be unwelcoming. I don't see
> > > clearly the argument of INFRA in the ticket.
> > >
> > > > The policy of no-write-access for bots is a requirement by the
> > > foundation legal team. We cannot allow write access to repos without an
> > > ICLA.
> > >
> > > Labeling and closing the PR in github does not imply write-access from
> > > the bot into the 'real' gitbox repository, so I don't see how this can
> > > be an issue, or are we in a gray area (in case bot automation of
> > > metadata can have legal issues which I doubt since this is not part of
> > > the source distribution).
> > >
> > > As a precedent we had Probot/Stale enabled for Apache Beam so I
> > > suppose that this should be possible for Airflow too.
> > > https://issues.apache.org/jira/browse/INFRA-16589
> > >
> > > On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
> > > >
> > > > Apache Airflow has, at any point, >200 PRs open. During the slower
> > summer
> > > > months, we've been merging 100-200 PRs a month. We have been growing
> > the
> > > > community -- we have <600 contributors, ~200 companies using it, and
> > 20+
> > > > committers. A person is promoted to "Committer" in recognition for
> work
> > > > he/she has done without an expectation of future work in maintaining
> > the
> > > > code base. Hence, minting new committers doesn't always translate
> into
> > > > greater bench strength where merging PRs is concerned. That said, we
> > are
> > > > actively adding new committers. The last 4-5 committers we added have
> > > been
> > > > super active maintainers, so the coverage on PRs and questions has
> been
> > > > getting better.
> > > >
> > > > There are many causes of Cold-case PRs:
> > > >
> > > >1. Submitter is not actively responding
> > > >   1. One example is that we requested tests and they were never
> > > written
> > > >   2. Discussion ensued on the PR and the submitter did not accept
> > the
> > > >   community's feedback
> > > >2. Committers didn't get to it in a timely manner and after a
> while
> > > the
> > > >engagement fell
> > > >
> > > > We are in a better position now to handle (2) -- this was not the
> case
> > a
> > > > year ago. We're at least able to keep up with our in-flow of PRs
> > > > week-to-week, but are still having challenges with the
> > > > previously-established backlog. But, (1) is also a contributor to
> stale
> > > PRs.
> > > >
> > > > We do have a lot of stale PRs to manually handle -- I spent all of
> > Summer
> > > > 2017 pinging submitters of old PRs and I find myself in the same
> > position
> > > > now.
> > > >
> > > > Probot/stale is a useful tool. It has legitimate use-cases. A policy
> > > > reflects the health/mentality/approaches of the community. A tool
> like
> > > this
> > > > enforces the policy. Let's not overlook adoption of what would be a
> > very
> > > > useful tool to the community due to a meta conversation about
> policy. I
> > > > think everyone on this list cares about growing a healthy and vibrant
> > > > community. We also care about being efficient with our spare time.
> > This
> > > > tools can help us manage both.
> > > >
> > > > Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs
> > need
> > > to
> > > > be kept open so we don't lose visibility of bugs/features/etc... This
> > > tool
> > > > doesn't handle JIRA closing anyway.
> > > >
> > > > -s
> > > >
> > > > On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas 
> wrote:
> > > >
> > > > > On 12/09/18 19:16, Sid Anand wrote:
> > > > > > A stale PR is defined by a policy -- for example, 60 days without
> > any
> > > > > > movement on the PR.
> > > > >
> > > > > Automatically closing such issues is not going to do anything to
> aid
> > > > > community building and is likely to 

Re: Auto-cleaning up Stale PRs

[Greg Stein]

Hello all,

The confusion here was "write access to the repository" (not allowed)
versus "write access to Pull Requests" (allowed). It took the Beam folks
some research to determine that GitHub *does* differentiate between these
two write capabilities (historically, GitHub has not been very granular
with permissions).

So. When Airflow said Probot Stale needed write access, we took that to
mean *code*.

After the pointer to Beam, reminding Infra of the research Beam had done
(and my enabling of Stale for them) ... we realized that Stale *is*
perfectly fine because it doesn't touch the code repository.

Probot Stale has been enabled for Airflow.

Cheers,
Greg Stein
Infrastructure Administrator, ASF


On Wed, Sep 19, 2018 at 7:47 PM Sid Anand  wrote:

> Ismael,
> Thanks for this pointer. I've re-opened my INFRA ticket and referenced your
> Apache Beam one. Super helpful.. if we get it enabled, please collect a
> beer from anyone in the Apache Airflow community!
>
> -s
>
> On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía  wrote:
>
> > While I agree that autoclosing PRs can be unwelcoming. I don't see
> > clearly the argument of INFRA in the ticket.
> >
> > > The policy of no-write-access for bots is a requirement by the
> > foundation legal team. We cannot allow write access to repos without an
> > ICLA.
> >
> > Labeling and closing the PR in github does not imply write-access from
> > the bot into the 'real' gitbox repository, so I don't see how this can
> > be an issue, or are we in a gray area (in case bot automation of
> > metadata can have legal issues which I doubt since this is not part of
> > the source distribution).
> >
> > As a precedent we had Probot/Stale enabled for Apache Beam so I
> > suppose that this should be possible for Airflow too.
> > https://issues.apache.org/jira/browse/INFRA-16589
> >
> > On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
> > >
> > > Apache Airflow has, at any point, >200 PRs open. During the slower
> summer
> > > months, we've been merging 100-200 PRs a month. We have been growing
> the
> > > community -- we have <600 contributors, ~200 companies using it, and
> 20+
> > > committers. A person is promoted to "Committer" in recognition for work
> > > he/she has done without an expectation of future work in maintaining
> the
> > > code base. Hence, minting new committers doesn't always translate into
> > > greater bench strength where merging PRs is concerned. That said, we
> are
> > > actively adding new committers. The last 4-5 committers we added have
> > been
> > > super active maintainers, so the coverage on PRs and questions has been
> > > getting better.
> > >
> > > There are many causes of Cold-case PRs:
> > >
> > >1. Submitter is not actively responding
> > >   1. One example is that we requested tests and they were never
> > written
> > >   2. Discussion ensued on the PR and the submitter did not accept
> the
> > >   community's feedback
> > >2. Committers didn't get to it in a timely manner and after a while
> > the
> > >engagement fell
> > >
> > > We are in a better position now to handle (2) -- this was not the case
> a
> > > year ago. We're at least able to keep up with our in-flow of PRs
> > > week-to-week, but are still having challenges with the
> > > previously-established backlog. But, (1) is also a contributor to stale
> > PRs.
> > >
> > > We do have a lot of stale PRs to manually handle -- I spent all of
> Summer
> > > 2017 pinging submitters of old PRs and I find myself in the same
> position
> > > now.
> > >
> > > Probot/stale is a useful tool. It has legitimate use-cases. A policy
> > > reflects the health/mentality/approaches of the community. A tool like
> > this
> > > enforces the policy. Let's not overlook adoption of what would be a
> very
> > > useful tool to the community due to a meta conversation about policy. I
> > > think everyone on this list cares about growing a healthy and vibrant
> > > community. We also care about being efficient with our spare time.
> This
> > > tools can help us manage both.
> > >
> > > Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs
> need
> > to
> > > be kept open so we don't lose visibility of bugs/features/etc... This
> > tool
> > > doesn't handle JIRA closing anyway.
> > >
> > > -s
> > >
> > > On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas  wrote:
> > >
> > > > On 12/09/18 19:16, Sid Anand wrote:
> > > > > A stale PR is defined by a policy -- for example, 60 days without
> any
> > > > > movement on the PR.
> > > >
> > > > Automatically closing such issues is not going to do anything to aid
> > > > community building and is likely to actively damage such efforts.
> > > >
> > > > > Stale PRs would be bad experiences in general for community
> members,
> > but
> > > > > after no movement for 60 days, this is just about cleaning up PRs
> > that
> > > > are
> > > > > not getting feedback from the committers or PR submitters.
> > > >
> > > > That is the wrong solution the 

Re: Auto-cleaning up Stale PRs

[Sid Anand]

Ismael,
Thanks for this pointer. I've re-opened my INFRA ticket and referenced your
Apache Beam one. Super helpful.. if we get it enabled, please collect a
beer from anyone in the Apache Airflow community!

-s

On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía  wrote:

> While I agree that autoclosing PRs can be unwelcoming. I don't see
> clearly the argument of INFRA in the ticket.
>
> > The policy of no-write-access for bots is a requirement by the
> foundation legal team. We cannot allow write access to repos without an
> ICLA.
>
> Labeling and closing the PR in github does not imply write-access from
> the bot into the 'real' gitbox repository, so I don't see how this can
> be an issue, or are we in a gray area (in case bot automation of
> metadata can have legal issues which I doubt since this is not part of
> the source distribution).
>
> As a precedent we had Probot/Stale enabled for Apache Beam so I
> suppose that this should be possible for Airflow too.
> https://issues.apache.org/jira/browse/INFRA-16589
>
> On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
> >
> > Apache Airflow has, at any point, >200 PRs open. During the slower summer
> > months, we've been merging 100-200 PRs a month. We have been growing the
> > community -- we have <600 contributors, ~200 companies using it, and 20+
> > committers. A person is promoted to "Committer" in recognition for work
> > he/she has done without an expectation of future work in maintaining the
> > code base. Hence, minting new committers doesn't always translate into
> > greater bench strength where merging PRs is concerned. That said, we are
> > actively adding new committers. The last 4-5 committers we added have
> been
> > super active maintainers, so the coverage on PRs and questions has been
> > getting better.
> >
> > There are many causes of Cold-case PRs:
> >
> >1. Submitter is not actively responding
> >   1. One example is that we requested tests and they were never
> written
> >   2. Discussion ensued on the PR and the submitter did not accept the
> >   community's feedback
> >2. Committers didn't get to it in a timely manner and after a while
> the
> >engagement fell
> >
> > We are in a better position now to handle (2) -- this was not the case a
> > year ago. We're at least able to keep up with our in-flow of PRs
> > week-to-week, but are still having challenges with the
> > previously-established backlog. But, (1) is also a contributor to stale
> PRs.
> >
> > We do have a lot of stale PRs to manually handle -- I spent all of Summer
> > 2017 pinging submitters of old PRs and I find myself in the same position
> > now.
> >
> > Probot/stale is a useful tool. It has legitimate use-cases. A policy
> > reflects the health/mentality/approaches of the community. A tool like
> this
> > enforces the policy. Let's not overlook adoption of what would be a very
> > useful tool to the community due to a meta conversation about policy. I
> > think everyone on this list cares about growing a healthy and vibrant
> > community. We also care about being efficient with our spare time.  This
> > tools can help us manage both.
> >
> > Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs need
> to
> > be kept open so we don't lose visibility of bugs/features/etc... This
> tool
> > doesn't handle JIRA closing anyway.
> >
> > -s
> >
> > On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas  wrote:
> >
> > > On 12/09/18 19:16, Sid Anand wrote:
> > > > A stale PR is defined by a policy -- for example, 60 days without any
> > > > movement on the PR.
> > >
> > > Automatically closing such issues is not going to do anything to aid
> > > community building and is likely to actively damage such efforts.
> > >
> > > > Stale PRs would be bad experiences in general for community members,
> but
> > > > after no movement for 60 days, this is just about cleaning up PRs
> that
> > > are
> > > > not getting feedback from the committers or PR submitters.
> > >
> > > That is the wrong solution the problem.
> > >
> > > If reporters of issues are not responding to questions and there is
> > > genuinely nothing the community can do to progress the issue without
> > > their input then closing the issue is fair enough. But that should very
> > > much be the exception rather than the rule. In projects I am involved
> in
> > > I probably do that a handful of times a year. However, even in a good
> > > chunk of those cases, the main reason for the lack of response from the
> > > OP is that the community did not respond to the original report for an
> > > excessively long time.
> > >
> > > If the committers are not responding to issues in a timely manner then
> > > the solution is to start looking for more committers.
> > >
> > > Reporting an issue is often the first interaction someone new to the
> > > community has with the project. It should be treated as an opportunity
> > > to attract new members to the community and to grow the project.
> > >
> > > Mark
> > 

Re: Auto-cleaning up Stale PRs

[Ismaël Mejía]

While I agree that autoclosing PRs can be unwelcoming. I don't see
clearly the argument of INFRA in the ticket.

> The policy of no-write-access for bots is a requirement by the foundation 
> legal team. We cannot allow write access to repos without an ICLA.

Labeling and closing the PR in github does not imply write-access from
the bot into the 'real' gitbox repository, so I don't see how this can
be an issue, or are we in a gray area (in case bot automation of
metadata can have legal issues which I doubt since this is not part of
the source distribution).

As a precedent we had Probot/Stale enabled for Apache Beam so I
suppose that this should be possible for Airflow too.
https://issues.apache.org/jira/browse/INFRA-16589

On Thu, Sep 13, 2018 at 5:55 PM Sid Anand  wrote:
>
> Apache Airflow has, at any point, >200 PRs open. During the slower summer
> months, we've been merging 100-200 PRs a month. We have been growing the
> community -- we have <600 contributors, ~200 companies using it, and 20+
> committers. A person is promoted to "Committer" in recognition for work
> he/she has done without an expectation of future work in maintaining the
> code base. Hence, minting new committers doesn't always translate into
> greater bench strength where merging PRs is concerned. That said, we are
> actively adding new committers. The last 4-5 committers we added have been
> super active maintainers, so the coverage on PRs and questions has been
> getting better.
>
> There are many causes of Cold-case PRs:
>
>1. Submitter is not actively responding
>   1. One example is that we requested tests and they were never written
>   2. Discussion ensued on the PR and the submitter did not accept the
>   community's feedback
>2. Committers didn't get to it in a timely manner and after a while the
>engagement fell
>
> We are in a better position now to handle (2) -- this was not the case a
> year ago. We're at least able to keep up with our in-flow of PRs
> week-to-week, but are still having challenges with the
> previously-established backlog. But, (1) is also a contributor to stale PRs.
>
> We do have a lot of stale PRs to manually handle -- I spent all of Summer
> 2017 pinging submitters of old PRs and I find myself in the same position
> now.
>
> Probot/stale is a useful tool. It has legitimate use-cases. A policy
> reflects the health/mentality/approaches of the community. A tool like this
> enforces the policy. Let's not overlook adoption of what would be a very
> useful tool to the community due to a meta conversation about policy. I
> think everyone on this list cares about growing a healthy and vibrant
> community. We also care about being efficient with our spare time.  This
> tools can help us manage both.
>
> Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs need to
> be kept open so we don't lose visibility of bugs/features/etc... This tool
> doesn't handle JIRA closing anyway.
>
> -s
>
> On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas  wrote:
>
> > On 12/09/18 19:16, Sid Anand wrote:
> > > A stale PR is defined by a policy -- for example, 60 days without any
> > > movement on the PR.
> >
> > Automatically closing such issues is not going to do anything to aid
> > community building and is likely to actively damage such efforts.
> >
> > > Stale PRs would be bad experiences in general for community members, but
> > > after no movement for 60 days, this is just about cleaning up PRs that
> > are
> > > not getting feedback from the committers or PR submitters.
> >
> > That is the wrong solution the problem.
> >
> > If reporters of issues are not responding to questions and there is
> > genuinely nothing the community can do to progress the issue without
> > their input then closing the issue is fair enough. But that should very
> > much be the exception rather than the rule. In projects I am involved in
> > I probably do that a handful of times a year. However, even in a good
> > chunk of those cases, the main reason for the lack of response from the
> > OP is that the community did not respond to the original report for an
> > excessively long time.
> >
> > If the committers are not responding to issues in a timely manner then
> > the solution is to start looking for more committers.
> >
> > Reporting an issue is often the first interaction someone new to the
> > community has with the project. It should be treated as an opportunity
> > to attract new members to the community and to grow the project.
> >
> > Mark
> >
> >
> > >
> > > -s
> > >
> > > On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher 
> > wrote:
> > >
> > >> Hi -
> > >>
> > >> I was pointing out a potential community problem which is what we are
> > >> about here in the Incubator.
> > >>
> > >> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
> > >>
> > >> A stale PR has not activity for some length of time.
> > >> https://github.com/probot/stale
> > >>
> > >> The policy file example shown on that link it pretty easy to 

Re: Auto-cleaning up Stale PRs

[Sid Anand]

Apache Airflow has, at any point, >200 PRs open. During the slower summer
months, we've been merging 100-200 PRs a month. We have been growing the
community -- we have <600 contributors, ~200 companies using it, and 20+
committers. A person is promoted to "Committer" in recognition for work
he/she has done without an expectation of future work in maintaining the
code base. Hence, minting new committers doesn't always translate into
greater bench strength where merging PRs is concerned. That said, we are
actively adding new committers. The last 4-5 committers we added have been
super active maintainers, so the coverage on PRs and questions has been
getting better.

There are many causes of Cold-case PRs:

   1. Submitter is not actively responding
  1. One example is that we requested tests and they were never written
  2. Discussion ensued on the PR and the submitter did not accept the
  community's feedback
   2. Committers didn't get to it in a timely manner and after a while the
   engagement fell

We are in a better position now to handle (2) -- this was not the case a
year ago. We're at least able to keep up with our in-flow of PRs
week-to-week, but are still having challenges with the
previously-established backlog. But, (1) is also a contributor to stale PRs.

We do have a lot of stale PRs to manually handle -- I spent all of Summer
2017 pinging submitters of old PRs and I find myself in the same position
now.

Probot/stale is a useful tool. It has legitimate use-cases. A policy
reflects the health/mentality/approaches of the community. A tool like this
enforces the policy. Let's not overlook adoption of what would be a very
useful tool to the community due to a meta conversation about policy. I
think everyone on this list cares about growing a healthy and vibrant
community. We also care about being efficient with our spare time.  This
tools can help us manage both.

Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs need to
be kept open so we don't lose visibility of bugs/features/etc... This tool
doesn't handle JIRA closing anyway.

-s

On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas  wrote:

> On 12/09/18 19:16, Sid Anand wrote:
> > A stale PR is defined by a policy -- for example, 60 days without any
> > movement on the PR.
>
> Automatically closing such issues is not going to do anything to aid
> community building and is likely to actively damage such efforts.
>
> > Stale PRs would be bad experiences in general for community members, but
> > after no movement for 60 days, this is just about cleaning up PRs that
> are
> > not getting feedback from the committers or PR submitters.
>
> That is the wrong solution the problem.
>
> If reporters of issues are not responding to questions and there is
> genuinely nothing the community can do to progress the issue without
> their input then closing the issue is fair enough. But that should very
> much be the exception rather than the rule. In projects I am involved in
> I probably do that a handful of times a year. However, even in a good
> chunk of those cases, the main reason for the lack of response from the
> OP is that the community did not respond to the original report for an
> excessively long time.
>
> If the committers are not responding to issues in a timely manner then
> the solution is to start looking for more committers.
>
> Reporting an issue is often the first interaction someone new to the
> community has with the project. It should be treated as an opportunity
> to attract new members to the community and to grow the project.
>
> Mark
>
>
> >
> > -s
> >
> > On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher 
> wrote:
> >
> >> Hi -
> >>
> >> I was pointing out a potential community problem which is what we are
> >> about here in the Incubator.
> >>
> >> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
> >>
> >> A stale PR has not activity for some length of time.
> >> https://github.com/probot/stale
> >>
> >> The policy file example shown on that link it pretty easy to follow, so
> >> I'll avoid pasting a wall of text into this email.
> >>
> >> This seems like a pretty valuable and much-needed piece of management-y
> >> software. Unfortunately, I was informed Apache Infra could not grant
> write
> >> perms to this GitHub plugin. I'd like to understand how we decide which
> >> plugins on GitHub get whitelisted?
> >>
> >>
> >> The Incubator does not make these decisions. The Apache Infrastructure
> >> team makes these.
> >>
> >> You can contact Infra - https://www.apache.org/dev/infra-contact
> >>
> >> Regards,
> >> Dave
> >>
> >>
> >> -s
> >>
> >> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher 
> wrote:
> >>
> >> Hi -
> >>
> >> What if the stale PR is from a new community member who is trying to
> make
> >> a contribution? Those should be handled by a committer with direct
> >> discussion.
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
> >>
> >> Im 

Re: Auto-cleaning up Stale PRs

[Mark Thomas]

On 12/09/18 19:16, Sid Anand wrote:
> A stale PR is defined by a policy -- for example, 60 days without any
> movement on the PR.

Automatically closing such issues is not going to do anything to aid
community building and is likely to actively damage such efforts.

> Stale PRs would be bad experiences in general for community members, but
> after no movement for 60 days, this is just about cleaning up PRs that are
> not getting feedback from the committers or PR submitters.

That is the wrong solution the problem.

If reporters of issues are not responding to questions and there is
genuinely nothing the community can do to progress the issue without
their input then closing the issue is fair enough. But that should very
much be the exception rather than the rule. In projects I am involved in
I probably do that a handful of times a year. However, even in a good
chunk of those cases, the main reason for the lack of response from the
OP is that the community did not respond to the original report for an
excessively long time.

If the committers are not responding to issues in a timely manner then
the solution is to start looking for more committers.

Reporting an issue is often the first interaction someone new to the
community has with the project. It should be treated as an opportunity
to attract new members to the community and to grow the project.

Mark


> 
> -s
> 
> On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher  wrote:
> 
>> Hi -
>>
>> I was pointing out a potential community problem which is what we are
>> about here in the Incubator.
>>
>> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
>>
>> A stale PR has not activity for some length of time.
>> https://github.com/probot/stale
>>
>> The policy file example shown on that link it pretty easy to follow, so
>> I'll avoid pasting a wall of text into this email.
>>
>> This seems like a pretty valuable and much-needed piece of management-y
>> software. Unfortunately, I was informed Apache Infra could not grant write
>> perms to this GitHub plugin. I'd like to understand how we decide which
>> plugins on GitHub get whitelisted?
>>
>>
>> The Incubator does not make these decisions. The Apache Infrastructure
>> team makes these.
>>
>> You can contact Infra - https://www.apache.org/dev/infra-contact
>>
>> Regards,
>> Dave
>>
>>
>> -s
>>
>> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher  wrote:
>>
>> Hi -
>>
>> What if the stale PR is from a new community member who is trying to make
>> a contribution? Those should be handled by a committer with direct
>> discussion.
>>
>> Regards,
>> Dave
>>
>> Sent from my iPhone
>>
>> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
>>
>> Im also interested in this PR policy automation.
>>
>> For Apache MXNet, there is no automation that I am aware of that handles
>> that. And it can be super helpful in handling stale PRs...
>>
>> Hagay
>>
>> On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
>>
>> Hi Folks!
>> I wanted a policy-driven approach to automatically label, comment, and
>> close inactive/stale PRs. Probot does this, but need some write perms to
>> GitHub.
>>
>> https://github.com/probot/stale
>>
>> I just learned this is not possible per
>> https://issues.apache.org/jira/browse/INFRA-17005
>>
>> How are other projects solving this problem? And why is probot not on
>>
>> say
>>
>> an approved list of GitHub integrations?
>>
>> -s
>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>>
>>
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Auto-cleaning up Stale PRs

[Sid Anand]

A stale PR is defined by a policy -- for example, 60 days without any
movement on the PR.

Stale PRs would be bad experiences in general for community members, but
after no movement for 60 days, this is just about cleaning up PRs that are
not getting feedback from the committers or PR submitters.

-s

On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher  wrote:

> Hi -
>
> I was pointing out a potential community problem which is what we are
> about here in the Incubator.
>
> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
>
> A stale PR has not activity for some length of time.
> https://github.com/probot/stale
>
> The policy file example shown on that link it pretty easy to follow, so
> I'll avoid pasting a wall of text into this email.
>
> This seems like a pretty valuable and much-needed piece of management-y
> software. Unfortunately, I was informed Apache Infra could not grant write
> perms to this GitHub plugin. I'd like to understand how we decide which
> plugins on GitHub get whitelisted?
>
>
> The Incubator does not make these decisions. The Apache Infrastructure
> team makes these.
>
> You can contact Infra - https://www.apache.org/dev/infra-contact
>
> Regards,
> Dave
>
>
> -s
>
> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher  wrote:
>
> Hi -
>
> What if the stale PR is from a new community member who is trying to make
> a contribution? Those should be handled by a committer with direct
> discussion.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
>
> Im also interested in this PR policy automation.
>
> For Apache MXNet, there is no automation that I am aware of that handles
> that. And it can be super helpful in handling stale PRs...
>
> Hagay
>
> On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
>
> Hi Folks!
> I wanted a policy-driven approach to automatically label, comment, and
> close inactive/stale PRs. Probot does this, but need some write perms to
> GitHub.
>
> https://github.com/probot/stale
>
> I just learned this is not possible per
> https://issues.apache.org/jira/browse/INFRA-17005
>
> How are other projects solving this problem? And why is probot not on
>
> say
>
> an approved list of GitHub integrations?
>
> -s
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>

Re: Auto-cleaning up Stale PRs

[Dave Fisher]

Hi -

I was pointing out a potential community problem which is what we are about 
here in the Incubator.

> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
> 
> A stale PR has not activity for some length of time.
> https://github.com/probot/stale
> 
> The policy file example shown on that link it pretty easy to follow, so
> I'll avoid pasting a wall of text into this email.
> 
> This seems like a pretty valuable and much-needed piece of management-y
> software. Unfortunately, I was informed Apache Infra could not grant write
> perms to this GitHub plugin. I'd like to understand how we decide which
> plugins on GitHub get whitelisted?

The Incubator does not make these decisions. The Apache Infrastructure team 
makes these.

You can contact Infra - https://www.apache.org/dev/infra-contact 


Regards,
Dave

> 
> -s
> 
> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher  wrote:
> 
>> Hi -
>> 
>> What if the stale PR is from a new community member who is trying to make
>> a contribution? Those should be handled by a committer with direct
>> discussion.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
>>> 
>>> Im also interested in this PR policy automation.
>>> 
>>> For Apache MXNet, there is no automation that I am aware of that handles
>>> that. And it can be super helpful in handling stale PRs...
>>> 
>>> Hagay
>>> 
 On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
 
 Hi Folks!
 I wanted a policy-driven approach to automatically label, comment, and
 close inactive/stale PRs. Probot does this, but need some write perms to
 GitHub.
 
 https://github.com/probot/stale
 
 I just learned this is not possible per
 https://issues.apache.org/jira/browse/INFRA-17005
 
 How are other projects solving this problem? And why is probot not on
>> say
 an approved list of GitHub integrations?
 
 -s
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Auto-cleaning up Stale PRs

[Sid Anand]

A stale PR has not activity for some length of time.
https://github.com/probot/stale

The policy file example shown on that link it pretty easy to follow, so
I'll avoid pasting a wall of text into this email.

This seems like a pretty valuable and much-needed piece of management-y
software. Unfortunately, I was informed Apache Infra could not grant write
perms to this GitHub plugin. I'd like to understand how we decide which
plugins on GitHub get whitelisted?

-s

On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher  wrote:

> Hi -
>
> What if the stale PR is from a new community member who is trying to make
> a contribution? Those should be handled by a committer with direct
> discussion.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
> >
> > Im also interested in this PR policy automation.
> >
> > For Apache MXNet, there is no automation that I am aware of that handles
> > that. And it can be super helpful in handling stale PRs...
> >
> > Hagay
> >
> >> On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
> >>
> >> Hi Folks!
> >> I wanted a policy-driven approach to automatically label, comment, and
> >> close inactive/stale PRs. Probot does this, but need some write perms to
> >> GitHub.
> >>
> >> https://github.com/probot/stale
> >>
> >> I just learned this is not possible per
> >> https://issues.apache.org/jira/browse/INFRA-17005
> >>
> >> How are other projects solving this problem? And why is probot not on
> say
> >> an approved list of GitHub integrations?
> >>
> >> -s
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Auto-cleaning up Stale PRs

[Dave Fisher]

Hi -

What if the stale PR is from a new community member who is trying to make a 
contribution? Those should be handled by a committer with direct discussion.

Regards,
Dave

Sent from my iPhone

> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
> 
> Im also interested in this PR policy automation.
> 
> For Apache MXNet, there is no automation that I am aware of that handles
> that. And it can be super helpful in handling stale PRs...
> 
> Hagay
> 
>> On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
>> 
>> Hi Folks!
>> I wanted a policy-driven approach to automatically label, comment, and
>> close inactive/stale PRs. Probot does this, but need some write perms to
>> GitHub.
>> 
>> https://github.com/probot/stale
>> 
>> I just learned this is not possible per
>> https://issues.apache.org/jira/browse/INFRA-17005
>> 
>> How are other projects solving this problem? And why is probot not on say
>> an approved list of GitHub integrations?
>> 
>> -s
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Auto-cleaning up Stale PRs

[Hagay Lupesko]

Im also interested in this PR policy automation.

For Apache MXNet, there is no automation that I am aware of that handles
that. And it can be super helpful in handling stale PRs...

Hagay

On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:

> Hi Folks!
> I wanted a policy-driven approach to automatically label, comment, and
> close inactive/stale PRs. Probot does this, but need some write perms to
> GitHub.
>
> https://github.com/probot/stale
>
> I just learned this is not possible per
> https://issues.apache.org/jira/browse/INFRA-17005
>
> How are other projects solving this problem? And why is probot not on say
> an approved list of GitHub integrations?
>
> -s
>

Auto-cleaning up Stale PRs

[Sid Anand]

Hi Folks!
I wanted a policy-driven approach to automatically label, comment, and
close inactive/stale PRs. Probot does this, but need some write perms to
GitHub.

https://github.com/probot/stale

I just learned this is not possible per
https://issues.apache.org/jira/browse/INFRA-17005

How are other projects solving this problem? And why is probot not on say
an approved list of GitHub integrations?

-s