Auto-cleaning up Stale PRs

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Dave Fisher-5
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Dave Fisher-5
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 <[hidden email]> 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.


Regards,
Dave


-s

On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Greg Stein-4
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]>
> > > > 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > 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 <[hidden email]>
> > 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 <[hidden email]> 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: [hidden email]
> > > > >> For additional commands, e-mail:
> [hidden email]
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Sid Anand
Thanks Greg and Ismael!
-s

On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <
> > [hidden email]>
> > > > > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > 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 <[hidden email]>
> > > 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 <[hidden email]>
> 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:
> [hidden email]
> > > > > >> For additional commands, e-mail:
> > [hidden email]
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Dave Fisher-5
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 <[hidden email]> wrote:
>
> Thanks Greg and Ismael!
> -s
>
>> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>>> [hidden email]>
>>>>>> 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 <[hidden email]>
>>> 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 <
>>> [hidden email]>
>>>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>> 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:
>> [hidden email]
>>>>>>>> For additional commands, e-mail:
>>> [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Sid Anand
Will do.

-s

On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher <[hidden email]> 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 <[hidden email]> wrote:
> >
> > Thanks Greg and Ismael!
> > -s
> >
> >> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> >> 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 <
> >>> [hidden email]>
> >>>>>> 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 <[hidden email]>
> >>> 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 <
> >>> [hidden email]>
> >>>>>> 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 <[hidden email]>
> >>>> 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 <[hidden email]>
> >> 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:
> >> [hidden email]
> >>>>>>>> For additional commands, e-mail:
> >>> [hidden email]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-cleaning up Stale PRs

Liang Chen
In reply to this post by Sid Anand
+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: [hidden email]
For additional commands, e-mail: [hidden email]