Come up with a user communication and support workflow

[choldgraf]

Once we have users on these hubs, we'll need a model for how they are expected to engage with technical support as well as engage with other users on hubs. In addition there are at least two different kinds of users: admin-level users and non-admin users.

What kinds of communication bottlenecks do we want? What kind of technical platforms should we use for this communication?

A few thoughts for tech platforms:

1. Slack
2. A Discourse site
3. GitHub issues in these repositories
4. An email address like support@2i2c.org that is forwarded to many of us
5. Pigeons with notes wrapped to their feet

In addition, how shall we break down the difference between pedagogical questions and support vs. technical questions and support? Perhaps having a single location for support will help us blur the lines between these a bit?

cc

@ericvd-ucb
@sandeepsainath
@sideye
@jamesgspercy
@yuvipanda

[choldgraf]

I was thinking about this a bit more, what about something like:

General workflow for users to report back

We use this repository for all questions from the users, via new issues. We can create a page on the 2i2c.org/pilot docs like "Contact the support team" that has links to a few different GitHub issue templates:

1. One for technical problems to report (e.g., "I got a 403 error when I tried to log in") (label: bug)
2. One for technical requests to request (e.g. "can a new package be added") (label: feature)
3. One for usage questions (e.g., "how do I create an interact link?") (label: question)

For technical issues

For technical issues, @jamesgspercy will monitor types 1 and 2 and provide first point-of-contact triage, assistance, and debugging. Most of these issues should be addressable through either debugging via the JupyterHub interface for a user, by monitoring the kubernetes cluster itself, and by making configurations to the pilot hubs repository.

If we run into issues that are bigger than that, @jamesgspercy will escalate to @yuvipanda to make more substantial improvements or debug major k8s problems. If 2i2c can find funding to pay for another engineer then we can also provide another person to support @jamesgspercy as well.

For usage / pedagogy issues

For usage / pedagogy issues, the Berkeley pedagogy team can provide primary point-of-contact and triage. This includes @sandeepsainath, @sideye, and @ericvd-ucb (or whatever teams they wish to put into this role). These questions will be more around usage and how to "best use" these tools. For more complex questions that dig into the guts of Jupyter etc, @choldgraf can also provide support and insight, and also help turn user questions into documentation for the pilots website.

What do folks think about this rough plan?

[choldgraf]

Note I have just added some templates to this repo here:

https://github.com/2i2c-org/pilot/issues/new/choose

and also added buttons for users to go to these templates here:

https://2i2c.org/pilot/use.html#user-guide

[sandeepsainath]

Looks comprehensive to me! A couple things on my mind:

1. Would support, atleast from Berkeley DSEP, be limited to GitHub issues as in the templates, or is it possible to redirect to an email? Perhaps filling out a short form of some kind that gets forwarded to us to reply back to. This email could either be our usual ds-help or a new dedicated email account.

2. Unsure if this is possible or if it's already implemented, but it might be worth adding in a "Support" or "Get Help" button on hubs themselves that redirects appropriately -- so if an admin is facing an issue while working on a hub, it's not too difficult to find help.

[yuvipanda]

I think adding a 'Support' button to the hub home page is great. What do you think, @choldgraf?

[choldgraf]

I think a support button is a great idea. My main question is "where does this button point?" :-)

we could have it point directly to: https://github.com/2i2c-org/pilot/issues/new/choose

I'm not sure how we could point people to different hub-specific support addresses (like ds-help for the cloudbank hubs) based on the project. Maybe that's not necessary though and instead we add a line that opens a mailto:support@2i2c.org?

[sandeepsainath]

I think it would be more appropriate to redirect to the mailto:support@2i2c.org on clicking on the Support button since admins would likely already be able to search up common issues on the GitHub, plus I'm not sure there would be a more direct way to ask an urgent-ish support question (aside from maybe navigating to a page on the website, which is slower).

[choldgraf]

We have this completed in https://docs.2i2c.org/en/latest/support.html