Evaluate support service options for requests with private information

[yuvipanda]

One of the primary characteristics of 'support' requests is that they might contain private information that should be visible to just the 2i2c engineers and the reporter. User names on the hub (if they are running into issues) is the most common piece of information that needs to be handled privately.

This makes a purely GitHub workflow difficult, since the medium of conversation needs to move completely off github as soon as a private piece of information is shared. Often this ends up being slack or email, with fracturing problems. This is a problem even with a single private repo, since private information will be visible to other organizations with access to the same private repo.

Looking at the larger picture, IMO it is important to separate 'support' requests (conversations between 2i2c and external hub users) from issue tracking. Privacy needs to be maintained, time sensitivity is different, and triage can happen differently. No matter what we use (GitHub or otherwise), we'll need to create explicit issues out of these support tickets (I think @damianavila pointed this out during the team meeting?). We'll probably need to handle prioritization differently too, based on who is asking.

I'd love for us to evaluate a bunch of support ticket tools (including GitHub), and form a process around that. Right now, this is just a number of us getting pinged in various slacks or gitter or Microsoft teams, and having a unified place for that would be <3

Potential options

• GitHub Issues (private or public repositoriy)
• GitLab (relevant docs)
• Freshdesk
• Azure Boards
• Discourse private groups/topics (see this thread for one guide)

Actions

• Discuss options for support
• Converge on one support service to try: we decided to use FreshDesk

[damianavila]

This is a problem even with a single private repo, since private information will be visible to other organizations with access to the same private repo.

This is a really great point that is preventing GitHub to be our support tool candidate, IMHO.
We could have a repo for each customer but that feels hacky and a lot of work...

I'd love for us to evaluate a bunch of support ticket tools (including GitHub), and form a process around that. Right now, this is just a number of us getting pinged in various slacks or gitter or Microsoft teams, and having a unified place for that would be <3

If we are going with another tool, that one should be our ONLY dedicated channel for support requests (to avoid these multiple pings in multiple platforms).

I guess our first task here is to come up with a list of possible candidate tools...

[yuvipanda]

If we are going with another tool, that one should be our ONLY dedicated channel for support requests (to avoid these multiple pings in multiple platforms).

I agree.

This is a really great point that is preventing GitHub to be our support tool candidate, IMHO.

I agree too, unfortunately

[choldgraf]

This is a great point about privacy. I asked around on Twitter, let's see if that surfaces anything

https://twitter.com/choldgraf/status/1414632656801869829?s=19

Actually one interesting response already notes that this is already possible in gitlab...

https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html#permissions-and-access-to-confidential-issues

[yuvipanda]

Last time I poked around in this, I quite liked Freshdesk. They seem to have GitHub integration too and weren't super expensive.

[yuvipanda]

Some baseline criteria for evaluating a support system:

1. Offers privacy controls for who can see what tickets
2. Integrates with GitHub, so we can 'link' issues to tickets. We can use GitHub to 'track work we need to do' and discussion around that.
3. The UX does not make us to never want to use the app
4. It integrates well with other tools we use (slack?)
5. It offers a single point of entry that we can point all our hub users to

I'd love for someone to evaluate some of these options and pick one to try :D

[yuvipanda]

Thinking about this some more, I would instead ask if someone is willing to trial run Freshdesk, just based on my research so far. Open to other options too!

[choldgraf]

I put a few options that I have heard about here and elsewhere in the top comment, which we can use to look into things

[damianavila]

A quick gut feeling... if we are going with a 3rd party tool, let's have a bias towards the tool specifically designed/intended to solve the "support" problem instead of tools trying to adapt to that "support" workflow into their existing (and different from support) system.

[choldgraf]

Hey all - since we need to make some progress on support right now, since @damianavila suggested we use a dedicated support service (and others have 👍 'ed it), since @yuvipanda has suggested FreshDesk as a good option, and since an hour of Googling suggests to me that FreshDesk is in-fact a reasonable choice here. How about this:

Proposal

Let's set up a FreshDesk account for 2i2c. I can create a plan and invite others on the team to join. We set up our team support processes to use FreshDesk and improve this as we learn more about it over time. We'll define our first Support Steward as soon as FreshDesk is set up, and then try out this workflow for 2i2c support.

In 2-3 months, we should assess how things are going with FreshDesk, if we like it, if we'd want to look into other options, etc. If not, then we keep using it. If so, then we trigger a deeper research process while we continue to use FreshDesk in the interrim.

Thoughts?

Do others agree with this as a short- and long-term plan? I think there is some downside that we haven't made "the right choice", but at the same time there's downside in not taking any action since we currently don't have much of a support structure in general. FreshDesk seems like a non-risky bet, and one that will help us build team processes around support regardless.

Curious what others think - unless somebody urges us not to do this in a day or two, I'll plan on setting up a FreshDesk account and seeing what this looks like.

[yuvipanda]

@choldgraf great plan! I fully support :D

[choldgraf]

OK I've opened up #167 to track setting up FreshDesk, so will close this one!