incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ismaël Mejía <ieme...@gmail.com>
Subject Re: Auto-cleaning up Stale PRs
Date Wed, 19 Sep 2018 14:38:49 GMT
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@apache.org> 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@apache.org> 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@comcast.net>
> > 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@apache.org> 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@comcast.net>
> > 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@gmail.com> 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@apache.org> 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@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

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


Mime
View raw message