git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Auto-cleaning up Stale PRs


Folks!
Probot/Stale <https://github.com/probot/stale> is now deployed and is
managing stale PRs :
https://github.com/apache/incubator-airflow/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3Astale

<https://github.com/probot/stale>
Probot/stale <https://github.com/probot/stale> is enforcing our policy file
<https://github.com/apache/incubator-airflow/blob/master/.github/stale.yml>.
It simply:

   - Looks for any PRs with no activity in 90 days (via *daysUntilStale*)
      - It then comments on the PR and marks the PR stale (using the stale
      label)
      - After 7 days (via *daysUntilClose*) of being labeled as stale, p/s
      will close the PR, again commenting on it
   - The JIRA will remain open, so that someone else can pick up the work
   at some future point
      - Notably, the JIRA assignee won't change, but folks should not be
      hindered by a pre-assigned JIRA with no movement over a long
period of time
      -- they should re-assign that JIRA to themselves
   - After being closed, the stale label remains on the PRs so we can
   assess how many were closed via this route over time.

This will at least address the management portion of cold case PRs and I
hope this will help the community better focus on active PRs (those with
active conversation on them). And of course, we hope the community can help
us curate the backlog of JIRAs.

A special thanks to Ismael from the Apache Beam community for unblocking us!

I will raise a PR shortly to drop the daysUntilStale to 45 or 60 days
-s

---------- Forwarded message ---------
From: Sid Anand <sanand@xxxxxxxxxx>
Date: Thu, Sep 20, 2018 at 7:56 AM
Subject: Re: Auto-cleaning up Stale PRs
To: <general@xxxxxxxxxxxxxxxxxxxx>


Will do.

-s

On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher <dave2wave@xxxxxxxxxxx> 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 <sanand@xxxxxxxxxx> wrote:
> >
> > Thanks Greg and Ismael!
> > -s
> >
> >> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <gstein@xxxxxxxxx> 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 <sanand@xxxxxxxxxx> 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 <iemejia@xxxxxxxxx>
> 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 <sanand@xxxxxxxxxx> 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 <markt@xxxxxxxxxx>
> >> 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 <
> >>> dave2wave@xxxxxxxxxxx>
> >>>>>> 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 <sanand@xxxxxxxxxx>
> >>> 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 <
> >>> dave2wave@xxxxxxxxxxx>
> >>>>>> 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 <lupesko@xxxxxxxxx>
> >>>> 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 <sanand@xxxxxxxxxx>
> >> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>> For additional commands, e-mail:
> >>> general-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: general-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>> For additional commands, e-mail: general-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: general-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>> For additional commands, e-mail: general-help@xxxxxxxxxxxxxxxxxxxx
> >>>>
> >>>>
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: general-help@xxxxxxxxxxxxxxxxxxxx
>
>