Add standard responses to issue bot

[chrmarti]

Adding standard responses to the issue bot that can be triggered by team members and in some cases the community.

The first stage focuses on simple cases so we can get these deployed early in the milestone and the team can use them for the issue cleanup:

• A team member adds a label and the bot closes the issue with a standard response in response.
  • Labels: question, extension-candidate, not-reproducible, out-of-scope
  • For each label there will be a standard comment in Markdown with links to more information.
• A team member can add a comment of the form '/duplicate of Sub menus by extensions in explorer context menus,item menus #12321' and the bot will label the issue as duplicate and close it with an explanatory comment.
• Issues closed for 30 days or longer are locked by the bot.

The second stage is slightly more complex and involves the community:

• Confirmation flow
  • A team member (or for some areas the bot) labels the issue as confirmation-needed and the bot adds an explanatory comment.
  • Anyone other than the issue's creator adds a comment of the from /confirm and the bot removes the confirmation-needed label and adds the confirmed label instead.
  • The owner is assigned by the inbox tracker (or automatically) when the issue is labeled confirmed.
• Vested community members: We will restrict the power to confirm an issue and extend the power to mark duplicates to active members of the community.
  • How this can be queried needs to be explored.

[chrmarti]

@Microsoft/vscode for feedback.

As a first stage (see description above) I propose to add the 4 auto-closing labels, the duplicate command and the auto-locking of closed issues with the following comments (none for locking) by the bot:

• *question:

This issue has been closed because it represents a question. Questions are better addressed on StackOverflow. See also our issue reporting guidelines.

Happy Coding!

• *extension-candidate:

This issue has been closed because it is not within the scope of the core product, but could be addressed by an extension. The VS Code Marketplace shows all existing extensions and you can get started writing your own extension in a few simple steps. See also our issue reporting guidelines.

Happy Coding!

• *not-reproducible:

This issue has been closed because the problem could not be reproduced either because it is already fixed in later versions of the product or because it requires additional details on how to reproduce it. See also our issue reporting guidelines.

Happy Coding!

• *out-of-scope:

This issue has been closed because the feature it requests is not within the scope of the product. See also our issue reporting guidelines.

Happy Coding!

• *duplicate:

This issue has been closed because it is already tracked by another issue. See also our GitHub issues to search for existing issues and our issue reporting guidelines.

Happy Coding!

[bpasero]

@chrmarti awesome, I like them all. Maybe we could also have caused-by-extension explaining how to report an issue to an extension? And what about issues that are not filed in english or just miss steps to reproduce, we could have a bad-quality label as well.

Since we have so many labels already, I would like to see these labels all prefixed with bot- or reply- so that it is faster to assign them.

[jrieken]

I like the categories and replies but I'd prefer to control the bot via comments, not labels. So, just reply to an issue with /question or /q and the bot replaces my comment with a standard reply and adds the label. IMO that's faster than typing in the label-selector

[jrieken]

Thank you for your contributions.

And obviously that would be 'Happy Coding' if it would be me 😎

[isidorn]

The one benefit of labels is that the user does not get notified about those.
So if you type something and user has email notifications he will see what you typed, not the bot message in his email.

[isidorn]

@chrmarti great proposal. I like that we split these into stages to make it more of an incremental thing.
I really like the predefined messages. I would only mention in the duplicate message that the user can search our issues to find the duplicate if he is passionate about it.

How about foreign-language or is that a subset of one of the catogories from above?

I would personally also benefit from labels try-without-extensions and try-on-insiders which would not close the issue but would post a predefined sentence and if the user does not come back with more data in a week would auto close it. My current flow is that I have to type the message myself and add needs-more-info

Stage two I will comment once we are done with stage one :)

[chrmarti]

• @bpasero I propose to use an asterisk as the prefix for bot powered labels. bot- or reply- seem too verbose to me and many labels do more than just reply.
• @jrieken Lets go with labels first because these don't trigger notifications.
• I like 'Happy Coding!' for being more casual.
• @isidorn Updated the duplicate message.
• Backlog: caused-by-extension, bad-quality, foreign-language (maybe included in bad-quality), try-without-extensions, try-on-insiders, as-designed

I have updated the proposal above.

[rebornix]

I like the combination of labeling and chatting ;) Speaking of non-English issues, I would propose below workflow/actions:

• Bot or Inbox tracker labels issues without good English explanation as ask-for-translation, leave a nice message, telling ppl we don't have expertise on this language and hope the author can translate it somehow someway or maybe better the community can help with it. Then close it.
• Issue author, community contributors or me (and Pine for Chinese ones), translate it with a prefix /translate.
• Bot automatically opens this issue, remove the label, analyze the translation, assign to proper owner.

This way non-English issues can be closed in a friendly way and reopened automatically when the info is enough, with the help from anyone possible.

[isidorn]

The problem with someone else giving translations is that the communication between the author and the vscode team member is slowed down and everytime new info is needed we have to wait for additional translation. Apart from that some translations might not be correct.
Also if vscode team members have questions for the non english speaking author than also those questions need to be translated from english.

A lot of hurdle imho

[octref]

@isidorn I think most of the time if you ask, the user would switch to English (even with help of Google translator) even if they opened their issues in other languages.
The idea is to allow the initial post to be foreign language and suggest ways for translation, but for the conversation to ensue always stick to English.

[chrmarti]

The proposed "first stage" is deployed. The locking has only made it through part of the issues and will need investigation.

[bpasero]

@chrmarti for "out of scope" I would propose different wording. Here is what I was using so far when I closed feature requests that are out of scope (especially we should point to our roadmap so that people understand our process):

This feature request will not be considered in the next [6-12 months roadmap](https://github.com/Microsoft/vscode/wiki/Roadmap) and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!

[isidorn]

Yeah @bpasero proposal is less harsh, usualy does the trick not pissing off the user

[jrieken]

@chrmarti Can you have n answer per label and chose one randomly when assigning? That will make us appear less that a robot and we can add a little variation to things.

[chrmarti]

I would be surprised if the repeated comments are an issue for the community, they shouldn't see them as often as we do. (I get that it is boring for us.)

I have updated the out of scope response to:

This feature request will not be considered in the next 6-12 months roadmap and has been closed to keep the number of issues we have to maintain manageable. See also our issue reporting guidelines.

Thanks for your understanding and happy coding!

[jrieken]

So, I do like the new workflow but it did increase the amount of notifications I receive. Before this would happen when dealing with a dupe for instance: (1) see and open a notification, (2) find out it's a dupe, (3) find the dupe, (4) closing that issue as dupe. Now, I have also step (5) get notified on the same item again because the bot closed it and (6) mark the item as read and/or unsubscribe from the issue...

[chrmarti]

Unfortunately there is no API for the bot to unsubscribe us first. (Previously you would also have to add the label, btw.)

[aeschli]

I find the latest 'out-of-scope' rather harsh. It just says 'will not be considered in the next 6-12 months roadmap' without explaining why.
Here's my suggestion:

To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed.
If you disagree and feel that this issue is crucial: We're happy to listen and to reconsider.
Maybe you want to give it a try yourself and provide the feature through an extension or a PR: We're happy to give advise and get you started.
Thanks for your understanding. Thanks for helping and happy coding!

[jens1o]

I really agree with @aeschli. I felt soo embarrassed and I was a bit disappointed in you guys, because you just close a(in my opinion) good suggestion. I even thought about no longer helping on GitHub. :/

[isidorn]

😢

[roblourens]

Another feedback #20084 (comment)

[chrmarti]

It is understandable that *out-of-scope is controversial. I'm happy to change the text there, not sure if we already agree on the new one.

#38912 suggests less formal responses:

• *question:

Please ask your question on StackOverflow. We have a great community over there. They have already answered thousands of questions and are happy to answer yours as well. See also our issue reporting guidelines.

Happy Coding!

• *extension-candidate:

We try to keep VS Code lean and we think the functionality you're asking for is great for a VS Code extension. Maybe you can already find one that suits you in the VS Code Marketplace. Just in case, in a few simple steps you can get started writing your own extension. See also our issue reporting guidelines.

Happy Coding!

• *not-reproducible:

We closed this issue because we are unable to reproduce the problem with the steps you describe. Chances are we've already fixed your problem in a recent version of VS Code. If not, please reopen the issue and provide us with more detail. Our issue reporting guidelines might help you with that.

Happy Coding!

• *out-of-scope:

Thanks for your idea! Unfortunately, we won't be able to implement it in the next 12 months. If you wonder what we are up to, please see our roadmap. We close issues that are not covered by the roadmap to keep the number of issues manageable. Thanks for understanding. As always, pull requests are welcome! See also our issue reporting guidelines.

Happy Coding!

• *duplicate:

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[jens1o]

As always, pull requests are welcome! See also our issue reporting guidelines.

Does this mean, that the feature request is going to be implemented once there is a pull request, even though you think it's out-of-scope?

[bpasero]

Please DO NOT include any message about pull requests being welcome. We are on GitHub, so it is quite obvious that PRs are possible. But I do not want to close an issue that is clearly out of scope only to spend the next weeks having to review a PR on that same thing that even I would not want to start working on in the first place.

[dbaeumer]

May be there are two different out of scope. Feature requests that would fit into the product which we don't have on the road map for the next 12 months. For those I guess we would consider a PR if it meets our quality bar. And features that will never make it into the product, regardless if a PR exists or not (for example a graphical editor). But I am not sure if we should distinguish them.

[aeschli]

Why mentioning '12 months'. It's not that we have a 12 month plan. The issues we close are also likely not being implemented later, as they have been on the backlog a while and haven't gained any traction (votes/duplicates) so far. But if they do, we are always happy to reconsider.

[jens1o]

The issues we close are also likely not being implemented later

Even simple features are making a hole product awesome and unique. ;)

Regarding @bpasero :

Please DO NOT include any message about pull requests being welcome. We are on GitHub, so it is quite obvious that PRs are possible.

Not every repository is looking for contributors or even collaborators from the community, but they only want to make it's product open-source, but leave development on their own. This is why I think it's important to explicitly say it, after all, you want to get new collaborators, don't you?

[chrmarti]

@jens1o Yes, we definitely want new contributors. I understand @bpasero's concern though.

[roblourens]

I think we have put out enough signals that we are looking for contributors in general but the message from the bot could sound like it's inviting PRs for that particular issue, which may or may not be the case.

[joaomoreno]

@chrmarti Could we get the *caused-by-extension tag working? As an inbox tracker that is, by far, the one I need the most.

[joaomoreno]

Also, could we get a GreaseMonkey script which gives intellisense on the comment box so we know which commands we can use?

[chrmarti]

Thanks for the feedback. I'm updating to the less formal texts listed above. I'm also changing *out-of-scope to what @aeschli suggests, but without the call for extensions (use *extension-candidate instead) or PRs (we already state elsewhere that we welcome contributions in general) and still include the links to our roadmap and issue reporting guidlines. I'm also adding a *caused-by-extension response to help with issue tracking.

• *out-of-scope:

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that have been on the backlog for a long time but have not gained traction: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

• *caused-by-extension:

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines.

Happy Coding!

[chrmarti]

Considering this done for the milestone.