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