Auto comment/close wrong-repo issues

[gibfahn]

trafficstars

We get a lot of issues raised that basically need to be closed with a link to the relevant repo. @mscdex does a heroic job of commenting (I assume with a saved reply) and closing all these¹, but it seems like something that could be automated. Having a bot do that would (IMO) make it feel less personal for the person whose issue is being closed.

^{1 See for example https://github.com/nodejs/node/issues/16710#issuecomment-341699548}

Proposal

If someone adds the wrong-repo label, the bot comments and closes the issue. @mscdex 's comment text seems perfect as a stock comment.

General help questions should be posted to the nodejs/help issue tracker instead. This issue tracker is for reporting bugs and submitting feature requests for node core. Issues with npm or other tools that use node should be posted to the appropriate issue tracker for those tools, unless it can be proven that the issue is in fact with node core and not the tool in question.

Follow-on proposal

What might be even more helpful is if a collaborator adds the question and wrong-repo labels, the github-bot "moves" the issue to nodejs/help.

Moving would mean:

• Raising a new issue in nodejs/help @mentioning the original issue raiser and linking to the original issue.
• Closing the nodejs/node issue with a stock comment linking to the new issue.

[joyeecheung]

The idea itself SGTM but when an issue is labeled with the wrong-repo, the "right repo" might not necessarily be nodejs/help, how can the bot know which repo to redirect the author to?

[gibfahn]

The idea itself SGTM but when an issue is labeled with the wrong-repo, the "right repo" might not necessarily be nodejs/help, how can the bot know which repo to redirect the author to?

My theory was that the bot would just close if wrong-repo was added by itself. If question was also added that would mean redirect to nodejs/help, and if npm was also added that would mean redirect to npm/npm. If it's useful and there are other common ones we could expand, but those two are about 80% of the use-cases in my experience.