Define a private channel for support

[choldgraf]

Now that a few folks have started using these hubs, we've had support requests come in that suggest we need at least two different communications channels:

1. Support requests that are generic and can be public
2. Requests that identify individuals or accounts, or cannot be public for other reasons

For 1, we can suggest github issues, but for 2 we should have an option for people to discuss more privately. What should we do for this?

My first thought was to create a support@2i2c.org that me, @yuvipanda , @jamesgspercy have access to that could be a single account for private support questions. If a question could be asked in public then we ask people to post there.

Longer term I am not sure of the best approach.

What do folks think?

[rabernat]

A couple of ideas that we have learned along the way in Pangeo

• Some people, particularly from underrepresented groups, will never ask questions in a public forum. If we really want to support them, we should just accept this and not try to change it.
• Github is especially intimidating to these people.
• Smaller branded forums like Discourse / Slack can feel more friendly and still provide a public record. This is an intermediate option.
• Prefect does something cool with slack where they can take a discussion and archive the whole thing as a github issue. (example)
• https://fire.fundersclub.com/ is awesome for email -> github issue

[choldgraf]

Some people, particularly from underrepresented groups, will never ask questions in a public forum. If we really want to support them, we should just accept this and not try to change it.

This is a good point - I think we've already experienced this with some users of the hubs.

Smaller branded forums like Discourse / Slack can feel more friendly and still provide a public record. This is an intermediate option.

I am a fan of Discourse (though it is expensive for non-profits...we may need to roll our own until we get enough $$$ to pay the $50 a month). I've also been considering GitHub Discussions, although I think it still feels inaccessibly-public in the way that you describe above. Also, I'm weary of depending more and more on microsoft...

I am a little worried about "yet another Slack" since in my experience people end up not paying much attention to it. Though perhaps it would be OK as long as 2i2c folks are paying attention to it, and users can just use it when they need it but not more regularly?

Prefect does something cool with slack where they can take a discussion and archive the whole thing as a github issue

This is really cool! We should totally look into how to do this...maybe it's just a slack plugin?

[yuvipanda]

Requests that identify individuals or accounts, or cannot be public for other reasons

I am trying out freshdesk.com for this. Created it and invited @choldgraf and @GeorgianaElena to it. This would be accessible to the admins of our hubs, as a way for them to escalate to us.

https://commons.wikimedia.org/wiki/Commons:OTRS is the 'private requests' side of Wikimedia. Something similar to Freshdesk, manned purely by volunteers with training & clearance for private data.

[choldgraf]

nice! thanks @yuvipanda - is it a "ticket management" kind of system? Or is more like a forum?

What benefits do you think it'd bring over, say, a private GitHub repository that we add all hub champions to?

[yuvipanda]

Definitely a customer service style ticket management system. Pretty sure it integrates well with everything though, including GitHub. I'll need to give it a serious try over the coming week, though. see if it adds any value to us, and can be used in a way that doesn't overwhelm us.

What benefits do you think it'd bring over, say, a private GitHub repository that we add all hub champions to?

Primary reason is what @rabernat said earlier in thread

Some people, particularly from underrepresented groups, will never ask questions in a public forum. If we really want to support them, we should just accept this and not try to change it. Github is especially intimidating to these people.

In addition, there are definitely user privacy issues at play. Many educational privacy policies treat list of classes a student is in as private information. We run into this problem over and over again at Berkeley, and have to resort to private slack messages...

This can be something we charge for too. I'd suspect something like the pilot educational hubs will need this far more than a pangeo hub.

[yuvipanda]

See https://support.freshdesk.com/support/solutions/articles/214680-the-github-app for example

[choldgraf]

Yeah that makes sense to me re: private messages. I think it's going to be a balance we will need to find. A few thoughts come to mind:

• I'm inclined to only use this for issues that really are hub-related (or need infra changes by a hub engineer), not for random debugging questions etc
  • But, how do we disentangle these from one another? Many folks use Discourse for this kind of thing as the "messy" first point of contact between users, and then escalate to official "ticketing" systems as bugs and actionable problems are identified. However, as you mention Discourse is a more "public" space than many are comfortable with.
• I want to encourage user->user help and interaction (or champion->user help), since many times someone thinks of something as "a bug", it is actually their own actions that need to be changed (e.g., they use too much memory in their code). I think we'll be in an anti-pattern if the freshdesk is being used for lots of questions where we respond "oh that's actually XYZ small change in your code, not a hub problem".

So I guess in sum, what I hope we can figure out is a system that:

1. Filters "hub engineer problems" from all other problems
2. Makes it possible for people to get answers on their own (or via help of a non-2i2c person) for non-hub engineer problems
3. Makes it possible for people to find answers to get support without asking questions (e.g. a knowledge base)
4. Is a comfortable space where users feel free to speak their mind and share their problems

Do you imagine using Freshdesk for all user support questions? Or just a subset and we use another space for other questions?

[yuvipanda]

Yeah, this balance is going to be hard. I agree with your goals for the system.

My current suggestion is we build a JupyterHub service accessible only to admins. It should tell them to:

1. Search in our documentation
2. Search in discourse / post in discourse
3. Post to freshdesk only if it contains private information, such as the name of students.

How does that sound?

[choldgraf]

As a start I think that sounds quite reasonable - we'll have to learn the best practices ourselves and adapt over time. I think if this is accessible only to admins then it will help a lot. I thought you wanted this to be accessible to all users but now I see the kind of communication you are trying to capture here - it is the "XYZ instructor sends us an email about a problem their student had but doesn't want to call-out anyone publicly" use-case

[yuvipanda]

XYZ instructor sends us an email about a problem their student had but doesn't want to call-out anyone publicly

Exactly this. I want to not expose this as an email inbox, and instead as something you'd post from a JupyterHub admin service with proper fields.

[GeorgianaElena]

From someone that hasn't felt so comfortable asking questions on public channels, I believe that having a way to do this in private makes a lot of sense :+1:. Also, I love the idea of being able to ask for help directly from your hub.

The only downside I see if that we're adding just another place of discussion to follow. Right now we have GitHub, Slack, Gitter and Discourse. Maybe there are ways to integrate these together into a "default" communication channel (possibly like we have some GitHub issues being linked to Slack).

[yuvipanda]

Maybe there are ways to integrate these together into a "default" communication channel (possibly like we have some GitHub issues being linked to Slack).

Yes! Freshdesk is already integrated with email, and we can integrate that with slack too.

[choldgraf]

yeah I agree @GeorgianaElena, I think there are two important pieces here:

1. Integrations so that people can follow the conversation in multiple places, as long as
   • We provide guidance for how people can ignore notifications etc for certain channels they don't want to use
   • There is still a single source of truth for where the "main" conversation is happening
2. Guidelines for "what kind of conversation happens where" that we fairly-closely follow, so you know where to look for certain kinds of info

[yuvipanda]

https://support.freshdesk.com/support/solutions/articles/206103-the-slack-app exists as well, so we could start off there?

(2) is pretty important. Here's a first draft of the things we're currently adding:

1. New hub requests go in through Google Form, to freshdesk. Freshdesk is the source of truth for this process, until we have a hub running. Additionally, we can sync Freshdesk with one of our GitHub repos, so that acts as a two-way-sync / archive.
2. Hub support requests from admins go to freshdesk. These are handled entirely within freshdesk. Once resolved, these might be extracted out into a documentation blurb.

Other things we need to fit in:

1. Slack
2. Email (including hello@2i2c.org)
3. Discourse (if / when we add it)
4. GitHub

[GeorgianaElena]

Great wrap-up, @yuvipanda! One more quick question, do we plan to continue using Gitter too? I believe there is a Gitter channel in place at the moment, right? Or can we replace this with Freshdesk?

[yuvipanda]

Ah, fun. So there's the other source of content - other people's channels we are in. For example, UToronto's Microsoft Teams setup, or Farallon's Gitter channel. I'm not sure what to do about these :|

[choldgraf]

I think we'll need to define some boundaries of where 2i2c is expected to pay attention. IMO if an organization requires that we join their communication space to converse with them, this is a "very dedicated support" situation that is a high-end hub (and thus more revenue we can use to cover the person's time).

Though one interesting note about Gitter is that it has been purchased and now runs on Matrix, which is a more generic web chat tech, and apparently has a Slack bridge: https://github.com/matrix-org/matrix-appservice-slack

[yuvipanda]

I love matrix and in an ideal world everything would just be on matrix. We should probably bridge gitter / slack easily.

[choldgraf]

I looked into using Discourse for this a bit more deeply and wanted to report back what I found.

In Discourse, you can define groups of arbitrary users. Each group also has its own messaging archive, each message is like a "topic" in the broader discourse forum.

Groups can be private or public, and you can control who can both read or post to a group. In addition, groups can use a public email address to both send and receive emails.

What some Discourse communities use is a support group that is made up of the "support team". This group is private (so that people can send sensitive requests to it), so only group members can access the message archive. Any new member added to the group gets the historical record of the archive as well.

There are two ways that users can post to the support group:

1. Via Discourse, they can send a DM directly to @support. This will open up a new topic in the "support" group and people can now have "many to one" conversation with the person that opened the ticket (but only available to the author + support).
2. Via email, they can send an email to youraddress@yourorg.com (you have to connect the email address). Any emails to this address will go to the support group, and replies to the resulting topic will be emailed back to the original emailer.

So in this way, you can have a single space for "support conversations" that are viewable only by the support team and the author of each individual support request. That space is usable both by Discourse users, and by anyone with an email address.

In case you'd like to test this out, I've created a demo support group on the Jupyter Discourse forum, and added @yuvipanda @GeorgianaElena and @consideRatio to it. In addition I've set up jupyter+support@discoursemail.com to open topics in that group's archive. Would be curious what you all think about it.

[aculich]

@choldgraf thanks for looping me into this thread— I'm currently building something like this for D-Lab consulting as a replacement for an old, crufty custom drupal system for our consulting request system. And we can't easily use things like zendesk, freshdesk, sprout, etc because the per-agent per-month cost is way too high when we have 50-100 student agents.

I'm implementing a solution right now that we're planning to launch in the next couple of weeks.

[aculich]

@yuvipanda could you add me to your test discourse & freshdesk instances? Both so I can see how you are setting things up, as well as help out... especially in setting up the pilot hubs that we'll be collaborating on?! Thanks!

[yuvipanda]

@aculich I'll try and find it in a few days! I didn't make any customizations though - just a zapier.com integration to move things from a Google form to it.

[choldgraf]

We've now got FreshDesk setup and we are tracking this in https://github.com/2i2c-org/team-compass/issues/167