+1 for the bot solution！ and I think Timo‘s suggestion is very useful！ Thanks， Jincheng
Timo Walther <twal...@apache.org>于2019年1月11日 周五22:44写道： > Thanks for bringing up this discussion again. +1 for a bot solution. > However, we should discuss a good process for closing PRs. > > In many cases, PRs are closed not because the contributor did not > respond but because no committer prioritizes the PR high enough. Or the > PR has issues that might not have been communicated clear enough (e.g. > bad code quality, big contribution that requires a big amount of time by > a reviewer). > > So maybe we can first introduce labels for better communication. Right > now, we don't use the label feature at all. > > For example, we could add a "Ownership needed" label by default. Because > why should a PR be closed if not a single committer opened at least the > description? > > Regards, > > Timo > > > > Am 11.01.19 um 12:36 schrieb qi luo: > > +1 for the stable bot, as it will help bring valuable PR out to be > reviewed. > > > >> On Jan 11, 2019, at 6:26 PM, Driesprong, Fokko <fo...@driesprong.frl> > wrote: > >> > >> +1 I'm in favor of the Stale bot. > >> > >> We use the Stalebot at Apache Airflow as well, and it really helps > smoothen > >> the reviewing process. Keep in mind that the number of PR's processed by > >> the Stalebot is limited at each run. So you won't get a gazillion > >> notifications, but just a few every couple of days. Just enough to prune > >> the list of PR's. > >> Most of the really old PR's are not relevant anymore, so its good > practice > >> to close these. If the person who still thinks it is relevant, the PR > will > >> be revisited and can still be considered merging. Otherwise, the PR > will be > >> closed by the bot. There is no value in having the old PR's hanging > around. > >> Having 500 open PR's doesn't look really good at the project in my > opinion. > >> My suggestion would be to give it a try. > >> > >> Cheers, Fokko > >> > >> Op do 10 jan. 2019 om 12:45 schreef Chesnay Schepler < > ches...@apache.org>: > >> > >>>> The bot will remind both reviewers and contributors that they have to > >>> be active on a PR, I found that useful on some PRs that I had open at > Beam > >>> > >>> I don't think we really want every contributor bumping their PR > >>> regularly. This will create unbearable noise and, if they actually > >>> update it, will lead to them wasting a lot of time since we won't > >>> suddenly start reviewing it. > >>> > >>> On 10.01.2019 12:06, Aljoscha Krettek wrote: > >>>> For reference, this is the older staleness discussion: > >>> > https://lists.apache.org/thread.html/d53bee8431776f38ebaf8f5678b1ffd9513cd65ce15d821bbdca95aa@%3Cdev.flink.apache.org%3E > >>> < > >>> > https://lists.apache.org/thread.html/d53bee8431776f38ebaf8f5678b1ffd9513cd65ce15d821bbdca95aa@%3Cdev.flink.apache.org%3E > >>>> > >>>> My main arguments for automatic closing of PRs are: > >>>> > >>>> - This will eventually close out old, stale PRs, making the number > we > >>> see in Github better reflect the actual state > >>>> - The bot will remind both reviewers and contributors that they have > >>> to be active on a PR, I found that useful on some PRs that I had open > at > >>> Beam > >>>> Aljoscha > >>>> > >>>>> On 10. Jan 2019, at 11:21, Chesnay Schepler <ches...@apache.org> > wrote: > >>>>> > >>>>> Without any new argument for doing so, I'm still against it. > >>>>> > >>>>> On 10.01.2019 09:54, Aljoscha Krettek wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I know we had similar discussions in the past but I’d like to bring > up > >>> this topic again. > >>>>>> What do you think about adding a stale bot ( > >>> https://probot.github.io/apps/stale/ < > https://probot.github.io/apps/stale/>) > >>> to our Github Repo? This would automatically nag about stale PRs and > close > >>> them after a (configurable) time of inactivity. This would do two > things: > >>>>>> (1) Clean up old PRs that truly are outdated and stale > >>>>>> (2) Remind both contributor and reviewers about PRs that are still > >>> good and are on the verge of getting stale, thus potentially speeding > up > >>> review or facilitating it in the first place > >>>>>> Best, > >>>>>> Aljoscha > >>> > >
