You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nope! This is a very general problem. I think this ticket was mostly to document that we are working on doing this for Express. I think we can report back on the solution and then set it in the documents like you mention.
For Express we have defined some very specific behavior we would like. To that end I started work last night on an GH Action to do this for us. You can see my very slim start here: https://github.com/pkgjs/triagebot
Express may do what it likes of course, but my experience with other projects use of bots for this tells me that an issue should never be closed except by a human, ideally with an explanation, or else it feels like a hostile action.
This is very much what we did not like about existing solutions. So the idea for the closing will be that it posts a message before closing which is nice. Nice in that it tells the user why and what they can do to repopen. It will also not arbitrarily close them, but will only do so for certain types of issues. For example, if there is a discuss tag, or a good first issue tag it would never close.
We have used the awaiting more info tag, so TBQH we might just close those if they never respond. The plan is a WIP :)
Yes I already knew about stale bot. There is a corresponding one built on top of new github actions as well. Neither implement the thing we talked about in the TC meeting. What you see in the code linked is the very beginning, What I planned was to start a scaffold showing a bit, but then open it up for express to start building all our custom triage requirements. The base code there will just be the framework which enables us to get the rest done.
Also, stalebot is actually exactly the thing which in my experience has been an issue in the past. It just randomly closes valid issues just because there was no activity. Maintainers not being available to answer a ticket does not equal resolved issues!
Activity
[-]Bot to Auto-Close ExpressJS bots[/-][+]Bot to Auto-Close ExpressJS issues[/+]pi0 commentedon Aug 30, 2019
Is this topic only limited to express ecosystem?
Things I would like to suggest discuss first if we planning to have more generally and vision/reasons for implementing a new bot:
wesleytodd commentedon Aug 30, 2019
Nope! This is a very general problem. I think this ticket was mostly to document that we are working on doing this for Express. I think we can report back on the solution and then set it in the documents like you mention.
For Express we have defined some very specific behavior we would like. To that end I started work last night on an GH Action to do this for us. You can see my very slim start here: https://github.com/pkgjs/triagebot
ljharb commentedon Aug 30, 2019
Express may do what it likes of course, but my experience with other projects use of bots for this tells me that an issue should never be closed except by a human, ideally with an explanation, or else it feels like a hostile action.
wesleytodd commentedon Aug 30, 2019
This is very much what we did not like about existing solutions. So the idea for the closing will be that it posts a message before closing which is nice. Nice in that it tells the user why and what they can do to repopen. It will also not arbitrarily close them, but will only do so for certain types of issues. For example, if there is a
discusstag, or agood first issuetag it would never close.We have used the
awaiting more infotag, so TBQH we might just close those if they never respond. The plan is a WIP :)Eomm commentedon Aug 31, 2019
Do you already know about stale bot?
Which features is it missing about auto-close?
Looking at the code I see an auto-label feature right?
wesleytodd commentedon Sep 1, 2019
Yes I already knew about stale bot. There is a corresponding one built on top of new github actions as well. Neither implement the thing we talked about in the TC meeting. What you see in the code linked is the very beginning, What I planned was to start a scaffold showing a bit, but then open it up for express to start building all our custom triage requirements. The base code there will just be the framework which enables us to get the rest done.
Also, stalebot is actually exactly the thing which in my experience has been an issue in the past. It just randomly closes valid issues just because there was no activity. Maintainers not being available to answer a ticket does not equal resolved issues!
styfle commentedon Dec 3, 2019
I am not a fan of stale bot for the above stated reasons 😉
https://twitter.com/styfle/status/1163946760135467010
jonchurch commentedon Jul 29, 2021
Express opted not to use bots to close or stale out issues, it's being done by hand. It's safe to close this one as resolved.