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 <ma...@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 <dave2w...@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 <san...@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 <dave2w...@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 <lupe...@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 <san...@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-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
