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 |
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 |
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 <[hidden email]> 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 > > |
> 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 <[hidden email]> 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 >> > |
+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 <[hidden email]>: > > 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 <[hidden email]> 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 > >> > > > > |
+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 <[hidden email]> 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 <[hidden email]>: > >>> 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 <[hidden email]> 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 >>>> >>> >> >> |
I carry on my +1 vote from the previous discussion.
Piotrek > On 11 Jan 2019, at 12:36, qi luo <[hidden email]> wrote: > > +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 <[hidden email]> 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 <[hidden email]>: >> >>>> 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 <[hidden email]> 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 >>>>> >>>> >>> >>> > |
In reply to this post by qi luo
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 <[hidden email]> 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 <[hidden email]>: >> >>>> 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 <[hidden email]> 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 >>> |
+1 for the bot solution!
and I think Timo‘s suggestion is very useful! Thanks, Jincheng Timo Walther <[hidden email]>于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 <[hidden email]> > 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 < > [hidden email]>: > >> > >>>> 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 <[hidden email]> > 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 > >>> > > |
+1 to try the bot solution and see how it goes.
On Fri, Jan 11, 2019 at 6:54 AM jincheng sun <[hidden email]> wrote: > +1 for the bot solution! > and I think Timo‘s suggestion is very useful! > Thanks, > Jincheng > > > Timo Walther <[hidden email]>于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 <[hidden email]> > > 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 < > > [hidden email]>: > > >> > > >>>> 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 <[hidden email]> > > 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 > > >>> > > > > > |
strong +1
The bot solution will make it easier to identify relevant PRs that need attention and clean up the somewhat depressing number of now stale PRs that are still open. To the point about noise being caused by contributors bumping their PRs. I believe we want that noise, since those are the PRs that are "active" and need attention. I think the onus is on the committers and PMC to find out how contributions from the community can be processed in a timely manner. Thomas On Fri, Jan 11, 2019 at 10:16 AM Jamie Grier <[hidden email]> wrote: > +1 to try the bot solution and see how it goes. > > On Fri, Jan 11, 2019 at 6:54 AM jincheng sun <[hidden email]> > wrote: > > > +1 for the bot solution! > > and I think Timo‘s suggestion is very useful! > > Thanks, > > Jincheng > > > > > > Timo Walther <[hidden email]>于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 <[hidden email] > > > > > 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 < > > > [hidden email]>: > > > >> > > > >>>> 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 <[hidden email]> > > > 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 > > > >>> > > > > > > > > > |
>
> Hey, > I agree with Timo here that we should introduce labels that will improve communication for PRs. IMHO this will show what percentage of PRs is really stale and not just abandoned due to the misunderstanding or other communication issues. Best Regards, Dom. |
+1 to try the bot.
It may, at first, seem less empathetic than a solution that involves a human monitoring the PRs, but, in essence, having a PR stale for months (or even years) is at least as discouraging for a new contributor. Labels could further reduce the problem of noise, but I think that this "noise" is a necessary evil during the "transition period" of moving from the current situation to one with cleaner PR backlog. Cheers, Kostas On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> wrote: > > > > Hey, > > > I agree with Timo here that we should introduce labels that will improve > communication for PRs. IMHO this will show what percentage of PRs is really > stale and not just abandoned due to the misunderstanding or other > communication issues. > > Best Regards, > Dom. > |
+1 to the bot, but -1 to the automatically closing PR behavior.
Can we just use the bolt to detect and tag the PR with stale flag and leave the decision whether to close the PR to the author? Best, Kurt On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas <[hidden email]> wrote: > +1 to try the bot. > > It may, at first, seem less empathetic than a solution that involves a > human monitoring the PRs, > but, in essence, having a PR stale for months (or even years) is at least > as discouraging for a > new contributor. > > Labels could further reduce the problem of noise, but I think that this > "noise" is a necessary evil > during the "transition period" of moving from the current situation to one > with cleaner PR backlog. > > Cheers, > Kostas > > On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> wrote: > > > > > > > Hey, > > > > > I agree with Timo here that we should introduce labels that will improve > > communication for PRs. IMHO this will show what percentage of PRs is > really > > stale and not just abandoned due to the misunderstanding or other > > communication issues. > > > > Best Regards, > > Dom. > > > |
I think the automatic closing is an integral part, without it we would never close those stale PRs that we have lying around from 2015 and 2016.
I would suggest to set the staleness interval quite high, say 2 months. Thus initially the bot would mainly close very old PRs and we shouldn’t even notice it on day-to-day PRs. It seems there is a larger consensus for adding the PR bot. By the way, keep in mind that we can always disable the bot again if we don’t like it. > On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: > > +1 to the bot, but -1 to the automatically closing PR behavior. > > Can we just use the bolt to detect and tag the PR with stale flag and leave > the decision whether to close the PR to the author? > > Best, > Kurt > > > On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas <[hidden email]> > wrote: > >> +1 to try the bot. >> >> It may, at first, seem less empathetic than a solution that involves a >> human monitoring the PRs, >> but, in essence, having a PR stale for months (or even years) is at least >> as discouraging for a >> new contributor. >> >> Labels could further reduce the problem of noise, but I think that this >> "noise" is a necessary evil >> during the "transition period" of moving from the current situation to one >> with cleaner PR backlog. >> >> Cheers, >> Kostas >> >> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> wrote: >> >>>> >>>> Hey, >>>> >>> I agree with Timo here that we should introduce labels that will improve >>> communication for PRs. IMHO this will show what percentage of PRs is >> really >>> stale and not just abandoned due to the misunderstanding or other >>> communication issues. >>> >>> Best Regards, >>> Dom. >>> >> |
+1 to try the bot out.
Regarding auto closing the PR's, worst case a PR can be reopened in the event of a false positive. Whereas tagging stale PR's and requiring further human intervention isn't accomplishing much in the grand scheme of things. Cheers, Cameron -- On Mon, 14 Jan 2019 at 09:34, Aljoscha Krettek <[hidden email]> wrote: > I think the automatic closing is an integral part, without it we would > never close those stale PRs that we have lying around from 2015 and 2016. > > I would suggest to set the staleness interval quite high, say 2 months. > Thus initially the bot would mainly close very old PRs and we shouldn’t > even notice it on day-to-day PRs. > > It seems there is a larger consensus for adding the PR bot. By the way, > keep in mind that we can always disable the bot again if we don’t like it. > > > On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: > > > > +1 to the bot, but -1 to the automatically closing PR behavior. > > > > Can we just use the bolt to detect and tag the PR with stale flag and > leave > > the decision whether to close the PR to the author? > > > > Best, > > Kurt > > > > > > On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas < > [hidden email]> > > wrote: > > > >> +1 to try the bot. > >> > >> It may, at first, seem less empathetic than a solution that involves a > >> human monitoring the PRs, > >> but, in essence, having a PR stale for months (or even years) is at > least > >> as discouraging for a > >> new contributor. > >> > >> Labels could further reduce the problem of noise, but I think that this > >> "noise" is a necessary evil > >> during the "transition period" of moving from the current situation to > one > >> with cleaner PR backlog. > >> > >> Cheers, > >> Kostas > >> > >> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> > wrote: > >> > >>>> > >>>> Hey, > >>>> > >>> I agree with Timo here that we should introduce labels that will > improve > >>> communication for PRs. IMHO this will show what percentage of PRs is > >> really > >>> stale and not just abandoned due to the misunderstanding or other > >>> communication issues. > >>> > >>> Best Regards, > >>> Dom. > >>> > >> > > |
In reply to this post by Aljoscha Krettek-2
For reference, I'm still very much -1 on this.
The short version is that auto-closing PRs hides symptoms that lead to stale PRs in the first place. As an example, consider flink-ml. We have a fair amount of open PRs targeted at this feature, that naturally this bot would close. What are they stale? Because at the time no committer was interested in them. Why are they still around? Because, despite seeing virtually no development for over 2(!!!) years, we still haven't officially declared flink-ml as dead. There is no note in the docs discouraging contributors from working on it, all the JIRAs still exist, and naturally the PRs were not closed because "maybe someone will look at the soon.". We have this issue also in other areas, like gelly, storm, python, streaming-python. WebUI PRs also routinely become stale. Is anyone asking why or how we could prevent that? Hell no. But sweeping it under a rug? /Sign me up/. Committers should proactively close PRs that will not be merged so that we can properly communicate to the contributor why this happened, reflect this decision in JIRA and possibly update the contribution guide as a means of preventing such PRs from being opened again. This also provides committers with a reference based on which they can close future PRs. Recommending contributors to continuously update their PRs to prevent them from being closed automatically is a terrible idea. This should only be recommended if a committer has actually taken interest in the PR and would be willing to review an updated version. Anything else completely disrespects the contributor's time, on the off-chance that they actually do so. On 14.01.2019 09:34, Aljoscha Krettek wrote: > I think the automatic closing is an integral part, without it we would never close those stale PRs that we have lying around from 2015 and 2016. > > I would suggest to set the staleness interval quite high, say 2 months. Thus initially the bot would mainly close very old PRs and we shouldn’t even notice it on day-to-day PRs. > > It seems there is a larger consensus for adding the PR bot. By the way, keep in mind that we can always disable the bot again if we don’t like it. > >> On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: >> >> +1 to the bot, but -1 to the automatically closing PR behavior. >> >> Can we just use the bolt to detect and tag the PR with stale flag and leave >> the decision whether to close the PR to the author? >> >> Best, >> Kurt >> >> >> On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas <[hidden email]> >> wrote: >> >>> +1 to try the bot. >>> >>> It may, at first, seem less empathetic than a solution that involves a >>> human monitoring the PRs, >>> but, in essence, having a PR stale for months (or even years) is at least >>> as discouraging for a >>> new contributor. >>> >>> Labels could further reduce the problem of noise, but I think that this >>> "noise" is a necessary evil >>> during the "transition period" of moving from the current situation to one >>> with cleaner PR backlog. >>> >>> Cheers, >>> Kostas >>> >>> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> wrote: >>> >>>>> Hey, >>>>> >>>> I agree with Timo here that we should introduce labels that will improve >>>> communication for PRs. IMHO this will show what percentage of PRs is >>> really >>>> stale and not just abandoned due to the misunderstanding or other >>>> communication issues. >>>> >>>> Best Regards, >>>> Dom. >>>> > |
I totally agree with Chesnay here. A bot just treats the symptoms but
not the cause. Maybe this needs no immediate action but we as committers should aim for a more honest communication. A lot of PRs have a reason for being stale but instead of communicating this reason we just don't touch them. But let's introduce a bot and see how it will affect the situation. Regards, Timo Am 14.01.19 um 15:19 schrieb Chesnay Schepler: > For reference, I'm still very much -1 on this. > > The short version is that auto-closing PRs hides symptoms that lead to > stale PRs in the first place. > > As an example, consider flink-ml. We have a fair amount of open PRs > targeted at this feature, that naturally this bot would close. > What are they stale? Because at the time no committer was interested > in them. Why are they still around? Because, despite seeing virtually > no development for over 2(!!!) years, we still haven't officially > declared flink-ml as dead. There is no note in the docs discouraging > contributors from working on it, all the JIRAs still exist, and > naturally the PRs were not closed because "maybe someone will look at > the soon.". > > We have this issue also in other areas, like gelly, storm, python, > streaming-python. WebUI PRs also routinely become stale. Is anyone > asking why or how we could prevent that? Hell no. But sweeping it > under a rug? /Sign me up/. > > Committers should proactively close PRs that will not be merged so > that we can properly communicate to the contributor why this happened, > reflect this decision in JIRA and possibly update the contribution > guide as a means of preventing such PRs from being opened again. This > also provides committers with a reference based on which they can > close future PRs. > > Recommending contributors to continuously update their PRs to prevent > them from being closed automatically is a terrible idea. This should > only be recommended if a committer has actually taken interest in the > PR and would be willing to review an updated version. > Anything else completely disrespects the contributor's time, on the > off-chance that they actually do so. > > On 14.01.2019 09:34, Aljoscha Krettek wrote: >> I think the automatic closing is an integral part, without it we >> would never close those stale PRs that we have lying around from 2015 >> and 2016. >> >> I would suggest to set the staleness interval quite high, say 2 >> months. Thus initially the bot would mainly close very old PRs and we >> shouldn’t even notice it on day-to-day PRs. >> >> It seems there is a larger consensus for adding the PR bot. By the >> way, keep in mind that we can always disable the bot again if we >> don’t like it. >> >>> On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: >>> >>> +1 to the bot, but -1 to the automatically closing PR behavior. >>> >>> Can we just use the bolt to detect and tag the PR with stale flag >>> and leave >>> the decision whether to close the PR to the author? >>> >>> Best, >>> Kurt >>> >>> >>> On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas >>> <[hidden email]> >>> wrote: >>> >>>> +1 to try the bot. >>>> >>>> It may, at first, seem less empathetic than a solution that involves a >>>> human monitoring the PRs, >>>> but, in essence, having a PR stale for months (or even years) is at >>>> least >>>> as discouraging for a >>>> new contributor. >>>> >>>> Labels could further reduce the problem of noise, but I think that >>>> this >>>> "noise" is a necessary evil >>>> during the "transition period" of moving from the current situation >>>> to one >>>> with cleaner PR backlog. >>>> >>>> Cheers, >>>> Kostas >>>> >>>> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> >>>> wrote: >>>> >>>>>> Hey, >>>>>> >>>>> I agree with Timo here that we should introduce labels that will >>>>> improve >>>>> communication for PRs. IMHO this will show what percentage of PRs is >>>> really >>>>> stale and not just abandoned due to the misunderstanding or other >>>>> communication issues. >>>>> >>>>> Best Regards, >>>>> Dom. >>>>> >> > > |
I agree with Chesnay here.
How about introducing a bot just to tag the stale PRs, not close them. Then we can get the numbers of how many stale PRs in there, and go farther according to the numbers. Best, Congxian Timo Walther <[hidden email]> 于2019年1月14日周一 下午10:30写道: > I totally agree with Chesnay here. A bot just treats the symptoms but > not the cause. > > Maybe this needs no immediate action but we as committers should aim for > a more honest communication. A lot of PRs have a reason for being stale > but instead of communicating this reason we just don't touch them. > > But let's introduce a bot and see how it will affect the situation. > > Regards, > Timo > > > Am 14.01.19 um 15:19 schrieb Chesnay Schepler: > > For reference, I'm still very much -1 on this. > > > > The short version is that auto-closing PRs hides symptoms that lead to > > stale PRs in the first place. > > > > As an example, consider flink-ml. We have a fair amount of open PRs > > targeted at this feature, that naturally this bot would close. > > What are they stale? Because at the time no committer was interested > > in them. Why are they still around? Because, despite seeing virtually > > no development for over 2(!!!) years, we still haven't officially > > declared flink-ml as dead. There is no note in the docs discouraging > > contributors from working on it, all the JIRAs still exist, and > > naturally the PRs were not closed because "maybe someone will look at > > the soon.". > > > > We have this issue also in other areas, like gelly, storm, python, > > streaming-python. WebUI PRs also routinely become stale. Is anyone > > asking why or how we could prevent that? Hell no. But sweeping it > > under a rug? /Sign me up/. > > > > Committers should proactively close PRs that will not be merged so > > that we can properly communicate to the contributor why this happened, > > reflect this decision in JIRA and possibly update the contribution > > guide as a means of preventing such PRs from being opened again. This > > also provides committers with a reference based on which they can > > close future PRs. > > > > Recommending contributors to continuously update their PRs to prevent > > them from being closed automatically is a terrible idea. This should > > only be recommended if a committer has actually taken interest in the > > PR and would be willing to review an updated version. > > Anything else completely disrespects the contributor's time, on the > > off-chance that they actually do so. > > > > On 14.01.2019 09:34, Aljoscha Krettek wrote: > >> I think the automatic closing is an integral part, without it we > >> would never close those stale PRs that we have lying around from 2015 > >> and 2016. > >> > >> I would suggest to set the staleness interval quite high, say 2 > >> months. Thus initially the bot would mainly close very old PRs and we > >> shouldn’t even notice it on day-to-day PRs. > >> > >> It seems there is a larger consensus for adding the PR bot. By the > >> way, keep in mind that we can always disable the bot again if we > >> don’t like it. > >> > >>> On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: > >>> > >>> +1 to the bot, but -1 to the automatically closing PR behavior. > >>> > >>> Can we just use the bolt to detect and tag the PR with stale flag > >>> and leave > >>> the decision whether to close the PR to the author? > >>> > >>> Best, > >>> Kurt > >>> > >>> > >>> On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas > >>> <[hidden email]> > >>> wrote: > >>> > >>>> +1 to try the bot. > >>>> > >>>> It may, at first, seem less empathetic than a solution that involves a > >>>> human monitoring the PRs, > >>>> but, in essence, having a PR stale for months (or even years) is at > >>>> least > >>>> as discouraging for a > >>>> new contributor. > >>>> > >>>> Labels could further reduce the problem of noise, but I think that > >>>> this > >>>> "noise" is a necessary evil > >>>> during the "transition period" of moving from the current situation > >>>> to one > >>>> with cleaner PR backlog. > >>>> > >>>> Cheers, > >>>> Kostas > >>>> > >>>> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> > >>>> wrote: > >>>> > >>>>>> Hey, > >>>>>> > >>>>> I agree with Timo here that we should introduce labels that will > >>>>> improve > >>>>> communication for PRs. IMHO this will show what percentage of PRs is > >>>> really > >>>>> stale and not just abandoned due to the misunderstanding or other > >>>>> communication issues. > >>>>> > >>>>> Best Regards, > >>>>> Dom. > >>>>> > >> > > > > > > -- Best, Congxian |
@Chesnay I agree that we did not handle PRs well at all in the past and we need to change more things than adding a stale bot to address them. I think, however, that a state bot is one piece of the solution for this because it makes the staleness of PRs more apparent. Plus, it will clean up those PRs that really are stale beyond rescue and therefore provide us a better number of really open PRs.
For me, the main point right now is that the bot will clean up old PRs (some of them from 2015) so that we get a more accurate number of open PRs. The bot will also tag state PRs with a “stale” label, which allows us to see at a glance (with a GitHub query) what PRs are stale. So far the two arguments I hear against adding a stale bot are: - It adds noise - Closing PRs is sweeping problems under the rug I think that an inaccurate number of PRs is more noise than a bot that reminds us (after say 2 months) about a PR. And the bot is actually the opposite of “sweeping things under the rug, before, stale PRs are being silently ignored and get forgotten. With a bot, there would be an automated system that makes sure we don’t silently sweep PRs under the rug. I see three groups of people that responded to this: - people that work on projects that have a stale PR. those people are very enthusiastic about adding such a bot to Flink - people that don’t work on projects that have a stale PR but are interested in trying it - people that don’t work on projects that have a stale PR but are very much against against adding such a bot There is no people that work on a project that have a stale PR but think it’s not a good idea. In my mind this makes it quite clear that we should add such a bot. As I said above, I don’t think the stale PR is the complete solution but it’s part of the solution. > On 15. Jan 2019, at 02:28, Congxian Qiu <[hidden email]> wrote: > > I agree with Chesnay here. > How about introducing a bot just to tag the stale PRs, not close them. Then > we can get the numbers of how many stale PRs in there, and go farther > according to the numbers. > > Best, > Congxian > > Timo Walther <[hidden email]> 于2019年1月14日周一 下午10:30写道: > >> I totally agree with Chesnay here. A bot just treats the symptoms but >> not the cause. >> >> Maybe this needs no immediate action but we as committers should aim for >> a more honest communication. A lot of PRs have a reason for being stale >> but instead of communicating this reason we just don't touch them. >> >> But let's introduce a bot and see how it will affect the situation. >> >> Regards, >> Timo >> >> >> Am 14.01.19 um 15:19 schrieb Chesnay Schepler: >>> For reference, I'm still very much -1 on this. >>> >>> The short version is that auto-closing PRs hides symptoms that lead to >>> stale PRs in the first place. >>> >>> As an example, consider flink-ml. We have a fair amount of open PRs >>> targeted at this feature, that naturally this bot would close. >>> What are they stale? Because at the time no committer was interested >>> in them. Why are they still around? Because, despite seeing virtually >>> no development for over 2(!!!) years, we still haven't officially >>> declared flink-ml as dead. There is no note in the docs discouraging >>> contributors from working on it, all the JIRAs still exist, and >>> naturally the PRs were not closed because "maybe someone will look at >>> the soon.". >>> >>> We have this issue also in other areas, like gelly, storm, python, >>> streaming-python. WebUI PRs also routinely become stale. Is anyone >>> asking why or how we could prevent that? Hell no. But sweeping it >>> under a rug? /Sign me up/. >>> >>> Committers should proactively close PRs that will not be merged so >>> that we can properly communicate to the contributor why this happened, >>> reflect this decision in JIRA and possibly update the contribution >>> guide as a means of preventing such PRs from being opened again. This >>> also provides committers with a reference based on which they can >>> close future PRs. >>> >>> Recommending contributors to continuously update their PRs to prevent >>> them from being closed automatically is a terrible idea. This should >>> only be recommended if a committer has actually taken interest in the >>> PR and would be willing to review an updated version. >>> Anything else completely disrespects the contributor's time, on the >>> off-chance that they actually do so. >>> >>> On 14.01.2019 09:34, Aljoscha Krettek wrote: >>>> I think the automatic closing is an integral part, without it we >>>> would never close those stale PRs that we have lying around from 2015 >>>> and 2016. >>>> >>>> I would suggest to set the staleness interval quite high, say 2 >>>> months. Thus initially the bot would mainly close very old PRs and we >>>> shouldn’t even notice it on day-to-day PRs. >>>> >>>> It seems there is a larger consensus for adding the PR bot. By the >>>> way, keep in mind that we can always disable the bot again if we >>>> don’t like it. >>>> >>>>> On 14. Jan 2019, at 03:33, Kurt Young <[hidden email]> wrote: >>>>> >>>>> +1 to the bot, but -1 to the automatically closing PR behavior. >>>>> >>>>> Can we just use the bolt to detect and tag the PR with stale flag >>>>> and leave >>>>> the decision whether to close the PR to the author? >>>>> >>>>> Best, >>>>> Kurt >>>>> >>>>> >>>>> On Sun, Jan 13, 2019 at 11:49 PM Kostas Kloudas >>>>> <[hidden email]> >>>>> wrote: >>>>> >>>>>> +1 to try the bot. >>>>>> >>>>>> It may, at first, seem less empathetic than a solution that involves a >>>>>> human monitoring the PRs, >>>>>> but, in essence, having a PR stale for months (or even years) is at >>>>>> least >>>>>> as discouraging for a >>>>>> new contributor. >>>>>> >>>>>> Labels could further reduce the problem of noise, but I think that >>>>>> this >>>>>> "noise" is a necessary evil >>>>>> during the "transition period" of moving from the current situation >>>>>> to one >>>>>> with cleaner PR backlog. >>>>>> >>>>>> Cheers, >>>>>> Kostas >>>>>> >>>>>> On Sun, Jan 13, 2019 at 1:02 PM Dominik Wosiński <[hidden email]> >>>>>> wrote: >>>>>> >>>>>>>> Hey, >>>>>>>> >>>>>>> I agree with Timo here that we should introduce labels that will >>>>>>> improve >>>>>>> communication for PRs. IMHO this will show what percentage of PRs is >>>>>> really >>>>>>> stale and not just abandoned due to the misunderstanding or other >>>>>>> communication issues. >>>>>>> >>>>>>> Best Regards, >>>>>>> Dom. >>>>>>> >>>> >>> >>> >> >> > > -- > Best, > Congxian |
Free forum by Nabble | Edit this page |