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 <san...@apache.org> wrote: > > Thanks Greg and Ismael! > -s > >> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <gst...@gmail.com> 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 <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 >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
