Standardised issue templates for all JupyterHub repositories

[manics]

Following on from jupyterhub/jupyterhub#3001.
I looked into whether we could define this once at the organisation level instead of updating each repo individually. This suggests we could by creating a new repository called .github:
https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/

Shall we give it go using the files from jupyterhub/jupyterhub#3001 ?

[GeorgianaElena]

What do you think about also using a bot like ranger or support to close and comment an issue once we label it with Technical Support or Should be on Discourse?

We can use @betatim's suggested text as the comment to the closed issue:

Hi there 👋!

Can we move this discussion to http://discourse.jupyter.org/ (where most of the people who hang out here also hang out, as well as more people). We are trying to streamline the different discussion places and want to use the issues on GitHub repos for technical discussions on how to change the contents of the repo. More general discussions should go to discourse so that they are easier to find, better indexed by google and generally more accessible than being hidden in the bowls of a GitHub repository ;)

Thanks!

[manics]

I created a repo to try out the support bot: https://github.com/manicstreetpreacher/test-bots/
Create an issue, then label it support and the bot should do its work.
I'll add people as collaborators with triage permissions so you can try out the labels.

[GeorgianaElena]

I just tried it and it works 🎊
One question: can the issue be re-opened by the maintainer after the bot closed it (as a collaborator, I couldn't do it)? I'm thinking that there might be situations where a support question might uncover a bug and we'd want to come back to the GitHub issue and post the resolution.

[manics]

@GeorgianaElena I've changed you fromTriage to Maintain:

Can you try now?

[GeorgianaElena]

Yep, it worked ✨

[choldgraf]

Two quick things:

1. I think it's a good idea to standardize issue / PR templates. My one concern is that there is value in having repository-specific information in some of them. But then again, I don't know that we really make strong use of this, and in reality it's more common that we have the same high-level information but presented slightly differently in each repo. So I think I'm OK with this as long as others agree as well.
2. For a bot, we need to be careful with the language. For example, in @manics's bot, it says "Can we...", but then it also closes the issue. That feels a bit passive-aggressive to me :-) I know this sounds like silly wordsmithing, but maybe if it were "Can you please..." instead of "can we" then it would be more like a request than a question, in which case closing the issue is reasonable.
3. Does anybody else think that @GeorgianaElena's celebration emoji 🎊 looks like a pacman vomiting confetti? #importantquestions

[sgibson91]

@choldgraf 100% agree on 3 😂 I also agree that tone of the message is super important in how people feel when a random bot closes their issue. Maybe vomiting pacmans will be useful there too?

P.S. The "Can we..." sentence Chris referenced, doesn't actually have a question mark at the end. Double passive-aggression! 😂 (@betatim please don't take any of this personally!)

[GeorgianaElena]

It was just a normal celebration emoji in my head. Now, I can't see anything else but the vomiting pacman 😂

[betatim]

We should most definitely tweak the text. I made one suggestion in manicstreetpreacher/test-bots#4 (comment) I think the bot should start with explaining what just happened and then stating what the reader can do to get their problem solved:

• "I closed this because it was labelled as a support question" and
• "Please repost this in the forum".
  Then explain a bit more why we use this policy. On a nteract repository a bot used to close&comment on stale issues. It used to say something like "the resource we are lacking is time. sorry we didn't get around to looking at this. You can help create more time for the maintainers by doing X, Y or Z." I used to like that because it told people something they could do to help improve the situation.

[choldgraf]

@betatim I like that text, I think it's more to-the-point 👍

[manics]

I've updated the text: manicstreetpreacher/test-bots@c259a01

I also discovered that removing the support label causes the bot to re-open the issue.

Edit: also tweaked the formatting, see the last example on manicstreetpreacher/test-bots#4

[GeorgianaElena]

I created a .github repository that has the support bot customized by @manics and the issue templates recently added to JH.

As @manics suggested in this comment #271 (comment), having a .github repo at the the org level, will create a set of default community health files that will be applied to all the repos within the organization (if a repo doesn't overwrite them).

Two things that I think are worth mentioning:

• The .github repository should work on a regular account also (not just an organization). However, it seems that for my account it doesn't have any effect on any of my repositories. People with similar issues created this thread and from what I understand a fix is on the way.
  P.S. I think it's possible that if we decide to transfer this repo at the org level it will work just fine 🤷‍♀️
• I'm note sure if we can also standardize the bot through this .github repo as its config isn't in the list of supported file types the docs.

[manics]

I'm note sure if we can also standardize the bot through this .github repo as its config isn't in the list of supported file types

Yes you can! See https://github.com/apps/support

Create .github/support.yml in the default branch to enable the app, or add it at the same file path to a repository named .github.

[GeorgianaElena]

Should I transfer the .github repo to the org and see the bot and issue templates in action 🚀 for all the JupyterHub repositories? WDYT?

[manics]

Sounds good to me!

[GeorgianaElena]

Turns out there was a .github repo already in the JupyterHub org, so I opened a PR there (jupyterhub/.github#1).