Update: you brought the information needed, and it is now enabled. Thanks for the follow-through!
Since you dug into probot's details, I took the liberty of assigning BEAM-4423 to you, in case throwing together the needed configs is fresh in your mind and you are in the mood to continue. (if not, pass the hot potato, back to me is OK too :-) Kenn On Thu, May 31, 2018 at 4:50 PM Alan Myrvold <amyrv...@google.com> wrote: > INFRA-16589 got closed asking to clarify that the probot-stale app would > not have permissions to merge automatically. > From my reading of the permissions documentation, it would not. I added a > comment to INFRA-16589 > > On Tue, May 29, 2018 at 10:05 AM Lukasz Cwik <lc...@google.com> wrote: > >> I opened up INFRA-16589 >> <https://issues.apache.org/jira/browse/INFRA-16589> for Apache infra to >> install Stale but they denied a similar request INFRA-16394 >> <https://issues.apache.org/jira/browse/INFRA-16394> because of >> permissions issues. I tried clarifying the permissions requested. >> >> On Tue, May 29, 2018 at 9:39 AM Scott Wegner <sweg...@google.com> wrote: >> >>> +1. I've opened BEAM-4423 to capture the discussion here: >>> https://issues.apache.org/jira/browse/BEAM-4423 >>> >>> On Thu, May 24, 2018 at 5:34 PM Chamikara Jayalath <chamik...@google.com> >>> wrote: >>> >>>> +1 for automatically closing. Currently, contribution guide mentions >>>> that pull requests without responses to actionable comments become stale >>>> (and closed) after two months but last I checked there were many pull >>>> requests that met this criteria but had not been closed after many months. >>>> So seems like humans are reluctant to act on the established policy :) >>>> >>>> - Cham >>>> >>>> On Wed, May 23, 2018 at 11:25 AM Kenneth Knowles <k...@google.com> >>>> wrote: >>>> >>>>> That makes sense, to just focus on Beam's decision. It seems the tool >>>>> is already built. I thought we just had to deploy it, but maybe not even >>>>> that, if we can just activate it: https://github.com/apps/stale >>>>> >>>>> Kenn >>>>> >>>>> On Wed, May 23, 2018 at 9:31 AM Ismaël Mejía <ieme...@gmail.com> >>>>> wrote: >>>>> >>>>>> Given that reaching consensus in both communities seems like a harder >>>>>> task >>>>>> than just deciding our policy. in the Beam side Why don't we just go >>>>>> ahead >>>>>> and vote around this + build the tool, and if the Flink guys are >>>>>> interested >>>>>> they can take it, no? >>>>>> >>>>>> in the future we can share that code. >>>>>> On Wed, May 16, 2018 at 3:31 PM Piotr Nowojski < >>>>>> pi...@data-artisans.com> >>>>>> wrote: >>>>>> >>>>>> > The question is what would such tool offer on top of over a >>>>>> Github’s view >>>>>> of PR sorted by “least recently updated”: >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc >>>>>> < >>>>>> https://github.com/apache/flink/pulls?q=is:pr+is:open+sort:updated-asc >>>>>> > >>>>>> >>>>>> > ? Maybe it would be good enough to have a policy about waiting x >>>>>> months/weeks for a contributor to respond. If he doesn’t, we either >>>>>> take >>>>>> over PR we or close it. Having “clean” view of oldest PRs would be >>>>>> beneficial for reviewing PRs in ~FIFO order as part of community work. >>>>>> >>>>>> > Having >>>>>> >>>>>> > > On 16 May 2018, at 10:57, Fabian Hueske <fhue...@gmail.com> >>>>>> wrote: >>>>>> > > >>>>>> > > Hi, >>>>>> > > >>>>>> > > I'm not objecting closing stale PRs. >>>>>> > > We have quite a few PRs with very little chance of being merged >>>>>> and I >>>>>> would >>>>>> > > certainly appreciate cleaning up those. >>>>>> > > However, I think we should not automate closing PRs for the >>>>>> reasons I >>>>>> gave >>>>>> > > before. >>>>>> > > >>>>>> > > A tool that reminds us of state PRs as proposed by Till seems >>>>>> like a >>>>>> good >>>>>> > > idea and might actually help to re-adjust priorities from time to >>>>>> time. >>>>>> > > >>>>>> > > @Yazdan: Right now there is no assignment happening. Committers >>>>>> decide >>>>>> > > which PRs they want to review and merge. >>>>>> > > >>>>>> > > Best, Fabian >>>>>> > > >>>>>> > > 2018-05-16 4:26 GMT+02:00 Yaz Sh <yazda...@gmail.com>: >>>>>> > > >>>>>> > >> I have questions in this regard (you guys might have addressed >>>>>> it in >>>>>> this >>>>>> > >> email chain): >>>>>> > >> how PRs get assigned to a reviewer apart of a contributor tag >>>>>> someone? >>>>>> > >> what if PR never gets a reviewer attention and it became >>>>>> in-active due >>>>>> to >>>>>> > >> long review respond? should Bot assign a reviewer to a PR based >>>>>> on >>>>>> > >> reviewers interest (i.e., defined via tags) and notify he/she if >>>>>> PR is >>>>>> > >> waiting for review? >>>>>> > >> >>>>>> > >> >>>>>> > >> Cheers, >>>>>> > >> /Yazdan >>>>>> > >> >>>>>> > >> >>>>>> > >>> On May 15, 2018, at 12:06 PM, Thomas Weise <t...@apache.org> >>>>>> wrote: >>>>>> > >>> >>>>>> > >>> I like Till's proposal to notify the participants on the PR to >>>>>> PTAL. >>>>>> But >>>>>> > >> I >>>>>> > >>> would also suggest to auto-close when no action is taken, with a >>>>>> friendly >>>>>> > >>> reminder that PRs can be reopened anytime. >>>>>> > >>> >>>>>> > >>> The current situation with 350 open PRs may send a signal to >>>>>> contributors >>>>>> > >>> that it may actually be too much hassle to get a change >>>>>> committed in >>>>>> > >> Flink. >>>>>> > >>> Since the count keeps on rising, this is also not a past >>>>>> problem. >>>>>> Pruning >>>>>> > >>> inactive PRs may help, that will also give a more accurate >>>>>> picture of >>>>>> the >>>>>> > >>> lack of review bandwidth, if that is the root cause. >>>>>> > >>> >>>>>> > >>> Thanks, >>>>>> > >>> Thomas >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> On Tue, May 15, 2018 at 8:24 AM, Ted Yu <yuzhih...@gmail.com> >>>>>> wrote: >>>>>> > >>> >>>>>> > >>>> How does the bot decide whether the PR is waiting for reviews >>>>>> or is >>>>>> > >> being >>>>>> > >>>> abandoned by contributor ? >>>>>> > >>>> >>>>>> > >>>> How about letting the bot count the number of times >>>>>> contributor pings >>>>>> > >>>> committer(s) for review ? >>>>>> > >>>> When unanswered ping count crosses some threshold, say 3, the >>>>>> bot >>>>>> > >> publishes >>>>>> > >>>> the JIRA and PR somewhere. >>>>>> > >>>> >>>>>> > >>>> Cheers >>>>>> > >>>> >>>>>> > >>>> On Tue, May 15, 2018 at 8:19 AM, Till Rohrmann < >>>>>> trohrm...@apache.org> >>>>>> > >>>> wrote: >>>>>> > >>>> >>>>>> > >>>>> I'm a bit torn here because I can see the pros and cons for >>>>>> both >>>>>> sides. >>>>>> > >>>>> >>>>>> > >>>>> Maybe a compromise could be to not have a closing but a >>>>>> monitoring >>>>>> bot >>>>>> > >>>>> which notifies us about inactive PRs. This could then trigger >>>>>> an >>>>>> > >>>>> investigation of the underlying problem and ultimately lead >>>>>> to a >>>>>> > >>>> conscious >>>>>> > >>>>> decision to close or keep the PR open. As such it is not >>>>>> strictly >>>>>> > >>>> necessary >>>>>> > >>>>> to have such a bot but it would at least remind us to make a >>>>>> decision >>>>>> > >>>> about >>>>>> > >>>>> older PRs with no activity. >>>>>> > >>>>> >>>>>> > >>>>> Cheers, >>>>>> > >>>>> Till >>>>>> > >>>>> >>>>>> > >>>>> On Tue, May 15, 2018 at 3:26 PM, Chesnay Schepler < >>>>>> ches...@apache.org> >>>>>> > >>>>> wrote: >>>>>> > >>>>> >>>>>> > >>>>>> /So far I did it twice for older PRs. In both cases I didn’t >>>>>> get >>>>>> any >>>>>> > >>>>>> response and I even forgot in which PRs I had asked this >>>>>> question, >>>>>> so >>>>>> > >>>>> now I >>>>>> > >>>>>> can not even close them :S/ >>>>>> > >>>>>> >>>>>> > >>>>>> To be honest this sounds more like an issue with how your >>>>>> organize >>>>>> > >> your >>>>>> > >>>>>> work. No amount of closing PRs can fix that. >>>>>> > >>>>>> With GitBox we can assign reviewers to a PR, but I'm not sure >>>>>> whether >>>>>> > >>>> it >>>>>> > >>>>>> only allows committers to assign people. >>>>>> > >>>>>> Bookmarks or text files might help as well./ >>>>>> > >>>>>> / >>>>>> > >>>>>> >>>>>> > >>>>>> /Regarding only 30% blocked on contributor. I wonder what >>>>>> would be >>>>>> > >> this >>>>>> > >>>>>> number if we tried to ask in the rest of old PRs “Hey, are >>>>>> you >>>>>> still >>>>>> > >>>>>> interested in reviewing/merging this?”. If old PR is >>>>>> waiting for a >>>>>> > >>>>>> reviewer for X months, it doesn’t mean that’s not abandoned. >>>>>> Even >>>>>> if >>>>>> > >> it >>>>>> > >>>>>> doesn’t, reducing our overhead by those 30% of the PRs is >>>>>> something./ >>>>>> > >>>>>> >>>>>> > >>>>>> No doubt the number would be higher if we were to go back, >>>>>> but as i >>>>>> > >>>>>> explained earlier that is not a reason to close it. If a PR >>>>>> is >>>>>> > >>>> abandoned >>>>>> > >>>>>> because we messed up we should still /try /to get it in. >>>>>> > >>>>>> >>>>>> > >>>>>> /This is kind of whole point of what I was proposing. If the >>>>>> PR >>>>>> author >>>>>> > >>>> is >>>>>> > >>>>>> still there, and can respond/bump/interrupt the closing >>>>>> timeout, >>>>>> > >> that’s >>>>>> > >>>>>> great. Gives us even more sense of urgency to review it./ >>>>>> > >>>>>> >>>>>> > >>>>>> Unfortunately knowing that it is more urgent is irrelevant, >>>>>> as we >>>>>> > >>>>>> currently don't have the manpower to review them. Reviving >>>>>> them now >>>>>> > >>>> would >>>>>> > >>>>>> serve no purpose. The alternative is to wait until more >>>>>> people >>>>>> become >>>>>> > >>>>>> active reviewers. >>>>>> > >>>>>> >>>>>> > >>>>>> /As a last resort, closing PR after timeout is not the end >>>>>> of the >>>>>> > >>>> world. >>>>>> > >>>>>> It always can be reopened./ >>>>>> > >>>>>> >>>>>> > >>>>>> Let's be realistic here, it will not be reopened. >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> On 15.05.2018 14:21, Piotr Nowojski wrote: >>>>>> > >>>>>> >>>>>> > >>>>>>> I agree that we have other, even more important, problems >>>>>> with >>>>>> > >>>> reviewing >>>>>> > >>>>>>> PR and community, but that shouldn’t block us from trying to >>>>>> clean up >>>>>> > >>>>>>> things a little bit and minimise the effort needed for >>>>>> reviewing >>>>>> PRs. >>>>>> > >>>>> Now >>>>>> > >>>>>>> before reviewing/picking older PRs I had to ask this “Hey, >>>>>> are you >>>>>> > >>>> still >>>>>> > >>>>>>> interested in merging this?” manually and wait for the >>>>>> response. >>>>>> If >>>>>> > >> it >>>>>> > >>>>>>> doesn’t come, I have to remember to go back and close PR, >>>>>> which I >>>>>> of >>>>>> > >>>>> course >>>>>> > >>>>>>> forget to do. Bah, so far I did it twice for older PRs. In >>>>>> both >>>>>> cases >>>>>> > >>>> I >>>>>> > >>>>>>> didn’t get any response and I even forgot in which PRs I >>>>>> had asked >>>>>> > >>>> this >>>>>> > >>>>>>> question, so now I can not even close them :S Wasted effort >>>>>> and >>>>>> > >> wasted >>>>>> > >>>>> time >>>>>> > >>>>>>> on context switching for me and for everyone else that will >>>>>> have >>>>>> to >>>>>> > >>>>> scroll >>>>>> > >>>>>>> pass or look on those PR to check their status. >>>>>> > >>>>>>> >>>>>> > >>>>>>> Keep in mind that I am not proposing to close the PR >>>>>> automatically >>>>>> > >>>>>>> straight on after 3 months of inactivity. Only after asking >>>>>> a >>>>>> > >> question >>>>>> > >>>>>>> whether original contributor is still there and he is >>>>>> interested >>>>>> in >>>>>> > >>>> the >>>>>> > >>>>> PR >>>>>> > >>>>>>> to be reviewed. >>>>>> > >>>>>>> >>>>>> > >>>>>>> for Flink 1.5, I merged a contribution from PR #1990 after >>>>>> it was >>>>>> > >>>>>>>> requested a few times by users. >>>>>> > >>>>>>>> >>>>>> > >>>>>>> This is kind of whole point of what I was proposing. If the >>>>>> PR >>>>>> author >>>>>> > >>>> is >>>>>> > >>>>>>> still there, and can respond/bump/interrupt the closing >>>>>> timeout, >>>>>> > >>>> that’s >>>>>> > >>>>>>> great. Gives us even more sense of urgency to review it. On >>>>>> the >>>>>> other >>>>>> > >>>>> hand >>>>>> > >>>>>>> if there is no response (no interest from the author for >>>>>> whatever >>>>>> the >>>>>> > >>>>>>> reasons) and nobody so far has picked this PR to >>>>>> review/merge, >>>>>> what’s >>>>>> > >>>>> the >>>>>> > >>>>>>> point of keeping such PR open? As a last resort, closing PR >>>>>> after >>>>>> > >>>>> timeout >>>>>> > >>>>>>> is not the end of the world. It always can be reopened. >>>>>> > >>>>>>> >>>>>> > >>>>>>> Regarding only 30% blocked on contributor. I wonder what >>>>>> would be >>>>>> > >> this >>>>>> > >>>>>>> number if we tried to ask in the rest of old PRs “Hey, are >>>>>> you >>>>>> still >>>>>> > >>>>>>> interested in reviewing/merging this?”. If old PR is >>>>>> waiting for a >>>>>> > >>>>> reviewer >>>>>> > >>>>>>> for X months, it doesn’t mean that’s not abandoned. Even if >>>>>> it >>>>>> > >>>> doesn’t, >>>>>> > >>>>>>> reducing our overhead by those 30% of the PRs is something. >>>>>> > >>>>>>> >>>>>> > >>>>>>> Piotrek >>>>>> > >>>>>>> >>>>>> > >>>>>>> On 15 May 2018, at 10:10, Fabian Hueske <fhue...@gmail.com> >>>>>> wrote: >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> I'm with Chesnay on this issue. >>>>>> > >>>>>>>> Stale PRs, i.e., a PR where a contributor becomes >>>>>> inactive, are >>>>>> one >>>>>> > >>>> of >>>>>> > >>>>>>>> our >>>>>> > >>>>>>>> smallest issues, IMO. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> There are more reasons for the high number of PRs. >>>>>> > >>>>>>>> * Lack of timely reviews. >>>>>> > >>>>>>>> * Not eagerly closing PRs that have no or very little >>>>>> chance of >>>>>> > >> being >>>>>> > >>>>>>>> merged. Common reasons are >>>>>> > >>>>>>>> 1) lack of interest in the feature by committers, >>>>>> > >>>>>>>> 2) too extensive changes and hence time consuming reviews, >>>>>> or >>>>>> > >>>>>>>> 3) bad quality. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> For 1), there are lots of older JIRA issues, that have low >>>>>> priority >>>>>> > >>>> but >>>>>> > >>>>>>>> which are picked up by contributors. In the contribution >>>>>> guidelines >>>>>> > >>>> we >>>>>> > >>>>>>>> ask >>>>>> > >>>>>>>> contributors to let us know when they want to work on an >>>>>> issue. >>>>>> So >>>>>> > >>>> far >>>>>> > >>>>>>>> our >>>>>> > >>>>>>>> attitude has been, yes sure go ahead. I've seen very little >>>>>> attempts >>>>>> > >>>> of >>>>>> > >>>>>>>> warning somebody to work on issues that won't be easily >>>>>> merged. >>>>>> > >>>>>>>> Once a PR has been opened, we should also be honest and let >>>>>> > >>>>> contributors >>>>>> > >>>>>>>> know that it has no chance or might take a while to get >>>>>> reviewed. >>>>>> > >>>>>>>> For 2) this is typically not so much of an issue if the >>>>>> feature >>>>>> is >>>>>> > >>>>>>>> interesting. However, if 1) and 2) meet, chances to get a >>>>>> change >>>>>> in >>>>>> > >>>>> drop >>>>>> > >>>>>>>> even more. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> A common "strategy" to deal with PRs that fall into 1), >>>>>> 2), or >>>>>> 3) is >>>>>> > >>>> to >>>>>> > >>>>>>>> not >>>>>> > >>>>>>>> look at them or giving a shallow review. >>>>>> > >>>>>>>> Of course, contributors become unresponsive if we don't >>>>>> look at >>>>>> > >> their >>>>>> > >>>>> PRs >>>>>> > >>>>>>>> for weeks or months. But that's not their fault. >>>>>> > >>>>>>>> Instead, I think we should be honest and communicate the >>>>>> chances >>>>>> of >>>>>> > >> a >>>>>> > >>>>> PR >>>>>> > >>>>>>>> more clearly. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> Browsing over the list of open PRs, I feel that most older >>>>>> PRs >>>>>> fall >>>>>> > >>>>> into >>>>>> > >>>>>>>> the category of low-priority (or even unwanted) features. >>>>>> > >>>>>>>> Bug fixes or features that the committers care about >>>>>> usually >>>>>> make it >>>>>> > >>>>> into >>>>>> > >>>>>>>> the code base. >>>>>> > >>>>>>>> In case a contributor becomes inactive, committers often >>>>>> take >>>>>> over >>>>>> > >> an >>>>>> > >>>>>>>> push >>>>>> > >>>>>>>> a contribution over the line. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> So, I do not support an auto-close mechanism. >>>>>> > >>>>>>>> I think a better way to address the issue is better >>>>>> communication, >>>>>> > >>>> more >>>>>> > >>>>>>>> eagerly closing PRs with no chance, and putting more >>>>>> reviewing >>>>>> > >>>> effort. >>>>>> > >>>>>>>> IMO, we should only eagerly close PRs that have no chance >>>>>> of >>>>>> being >>>>>> > >>>>>>>> merged. >>>>>> > >>>>>>>> PRs with low-prio features might be picked up later (for >>>>>> Flink >>>>>> 1.5, >>>>>> > >> I >>>>>> > >>>>>>>> merged a contribution from PR #1990 after it was requested >>>>>> a few >>>>>> > >>>> times >>>>>> > >>>>> by >>>>>> > >>>>>>>> users). >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> However, I think we could do a pass over the oldest PRs and >>>>>> check if >>>>>> > >>>> we >>>>>> > >>>>>>>> can >>>>>> > >>>>>>>> close a bunch. >>>>>> > >>>>>>>> There are quite a few contributions (many for flink-ml) >>>>>> that I >>>>>> don't >>>>>> > >>>>> see >>>>>> > >>>>>>>> a >>>>>> > >>>>>>>> chance for getting merged. >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> Best, Fabian >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> - >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> 2018-05-15 9:13 GMT+02:00 Chesnay Schepler < >>>>>> ches...@apache.org>: >>>>>> > >>>>>>>> >>>>>> > >>>>>>>> -1 >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> For clarification (since the original mail indicates >>>>>> otherwise), >>>>>> > >> the >>>>>> > >>>>>>>>> number of pull requests that this would affect is fairly >>>>>> small. >>>>>> > >>>>>>>>> Only about 25-30% of all open PRs are blocked on the >>>>>> contributor, >>>>>> > >>>> the >>>>>> > >>>>>>>>> remaining ones are actually blocked on the review. >>>>>> > >>>>>>>>> Thus is reject the premise that one has to search through >>>>>> that >>>>>> many >>>>>> > >>>>> PRs >>>>>> > >>>>>>>>> to >>>>>> > >>>>>>>>> find something to review, there is plenty. >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> I believe it to be highly unfair for us to close PRs due >>>>>> to >>>>>> > >>>>> inactivity, >>>>>> > >>>>>>>>> when the primary cause has been /our /own inactivity. >>>>>> > >>>>>>>>> If a PR is opened and the first comment comes in 3 months >>>>>> late, >>>>>> > >>>> then I >>>>>> > >>>>>>>>> don't blame the contributor for not responding. >>>>>> > >>>>>>>>> IMO we owe it to the contributor to evaluate their PR, >>>>>> and if >>>>>> > >>>>> necessary >>>>>> > >>>>>>>>> bring it to a merge-able state (to a certain extend). >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> There's also the fact that closing these PRs outright >>>>>> would >>>>>> waste a >>>>>> > >>>>> lot >>>>>> > >>>>>>>>> of >>>>>> > >>>>>>>>> good contributions. >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> Finally, this solution is overkill for what we want to >>>>>> achieve. >>>>>> If >>>>>> > >>>> we >>>>>> > >>>>>>>>> want >>>>>> > >>>>>>>>> to make it easier to find PRs to review all we need is >>>>>> > >>>>>>>>> GitBox integration and tagging or PRs. That's it. We >>>>>> could have >>>>>> a >>>>>> > >>>>> /fully >>>>>> > >>>>>>>>> /tagged PR list /tomorrow/, if we really wanted to. >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> On 15.05.2018 05:10, Ted Yu wrote: >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> bq. this pull request requires a review, please simply >>>>>> write any >>>>>> > >>>>>>>>>> comment. >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> Shouldn't the wording of such comment be known before >>>>>> hand ? >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> Otherwise pull request waiting for committers' review >>>>>> may be >>>>>> > >>>>>>>>>> mis-classified. >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> Cheers >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> On Mon, May 14, 2018 at 7:59 PM, blues zheng < >>>>>> kisim...@163.com> >>>>>> > >>>>> wrote: >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> +1 for the proposal. >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> Best, >>>>>> > >>>>>>>>>>> blues >>>>>> > >>>>>>>>>>> On 05/14/2018 20:58, Ufuk Celebi wrote: >>>>>> > >>>>>>>>>>> Hey Piotr, >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> thanks for bringing this up. I really like this >>>>>> proposal and >>>>>> also >>>>>> > >>>>> saw >>>>>> > >>>>>>>>>>> it work successfully at other projects. So +1 from my >>>>>> side. >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> - I like the approach with a notification one week >>>>>> before >>>>>> > >>>>>>>>>>> automatically closing the PR >>>>>> > >>>>>>>>>>> - I think a bot will the best option as these kinds of >>>>>> things >>>>>> are >>>>>> > >>>>>>>>>>> usually followed enthusiastically in the beginning but >>>>>> eventually >>>>>> > >>>>>>>>>>> loose traction >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> We can enable better integration with GitHub by using >>>>>> ASF >>>>>> GitBox >>>>>> > >>>>>>>>>>> (https://gitbox.apache.org/setup/) but we should >>>>>> discuss that >>>>>> in >>>>>> > >>>> a >>>>>> > >>>>>>>>>>> separate thread. >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> – Ufuk >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> On Mon, May 14, 2018 at 12:04 PM, Piotr Nowojski >>>>>> > >>>>>>>>>>> <pi...@data-artisans.com> wrote: >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> Hey, >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> We have lots of open pull requests and quite some of >>>>>> them are >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> stale/abandoned/inactive. Often such old PRs are >>>>>> impossible >>>>>> to >>>>>> > >>>>> merge >>>>>> > >>>>>>>>>>> due >>>>>> > >>>>>>>>>>> to >>>>>> > >>>>>>>>>>> conflicts and it’s easier to just abandon and rewrite >>>>>> them. >>>>>> > >>>>> Especially >>>>>> > >>>>>>>>>>> there are some PRs which original contributor created >>>>>> long >>>>>> time >>>>>> > >>>> ago, >>>>>> > >>>>>>>>>>> someone else wrote some comments/review and… that’s >>>>>> about it. >>>>>> > >>>>> Original >>>>>> > >>>>>>>>>>> contributor never shown up again to respond to the >>>>>> comments. >>>>>> > >>>>>>>>>>> Regardless >>>>>> > >>>>>>>>>>> of >>>>>> > >>>>>>>>>>> the reason such PRs are clogging the GitHub, making it >>>>>> difficult >>>>>> > >>>> to >>>>>> > >>>>>>>>>>> keep >>>>>> > >>>>>>>>>>> track of things and making it almost impossible to find >>>>>> a >>>>>> little >>>>>> > >>>> bit >>>>>> > >>>>>>>>>>> old >>>>>> > >>>>>>>>>>> (for example 3+ months) PRs that are still valid and >>>>>> waiting >>>>>> for >>>>>> > >>>>>>>>>>> reviews. >>>>>> > >>>>>>>>>>> To do something like that, one would have to dig >>>>>> through tens >>>>>> or >>>>>> > >>>>>>>>>>> hundreds >>>>>> > >>>>>>>>>>> of abandoned PRs. >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> What I would like to propose is to agree on some >>>>>> inactivity >>>>>> dead >>>>>> > >>>>> line, >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> lets say 3 months. After crossing such deadline, PRs >>>>>> should >>>>>> be >>>>>> > >>>>>>>>>>> marked/commented as “stale”, with information like: >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> “This pull request has been marked as stale due to 3 >>>>>> months of >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> inactivity. It will be closed in 1 week if no further >>>>>> activity >>>>>> > >>>>>>>>>>> occurs. If >>>>>> > >>>>>>>>>>> you think that’s incorrect or this pull request >>>>>> requires a >>>>>> > >> review, >>>>>> > >>>>>>>>>>> please >>>>>> > >>>>>>>>>>> simply write any comment.” >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> Either we could just agree on such policy and enforce it >>>>>> manually >>>>>> > >>>>>>>>>>>> (maybe >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> with some simple tooling, like a simple script to list >>>>>> inactive >>>>>> > >>>>> PRs - >>>>>> > >>>>>>>>>>> seems >>>>>> > >>>>>>>>>>> like couple of lines in python by using PyGithub) or we >>>>>> could >>>>>> > >>>> think >>>>>> > >>>>>>>>>>> about >>>>>> > >>>>>>>>>>> automating this action. There are some bots that do >>>>>> exactly >>>>>> this >>>>>> > >>>>> (like >>>>>> > >>>>>>>>>>> this >>>>>> > >>>>>>>>>>> one: https://github.com/probot/stale < >>>>>> https://github.com/probot/ >>>>>> > >>>>> stale >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>> ), >>>>>> > >>>>>>>>>>> but probably they would need to be adopted to >>>>>> limitations of >>>>>> our >>>>>> > >>>>>>>>>>> Apache >>>>>> > >>>>>>>>>>> repository (we can not add labels and we can not close >>>>>> the PRs >>>>>> > >> via >>>>>> > >>>>>>>>>>> GitHub). >>>>>> > >>>>>>>>>>> >>>>>> > >>>>>>>>>>> What do you think about it? >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> Piotrek >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>>>>> >>>>>> > >>>>>>>>> >>>>>> > >>>>>>> >>>>>> > >>>>>> >>>>>> > >>>>> >>>>>> > >>>> >>>>>> > >> >>>>>> > >> >>>>>> >>>>>
