Brainstorm, agree, and document support ticket management

[consideRatio]

Let's summarize support ticket management ideas we have here! If we can collect a lot of these ideas, we may be able to find agreement and refine such agreements into something to document.

Action points

• [ ] Brainstorming phase - write down support ticket management ideas in comments
• [ ] Agreement phase - figure out what we agree on
• [ ] Documentation phase - summarize what we agree on in documentation

[consideRatio]

Here are mine initial ideas

Collaborative practices

1. Edit ticket's titles to include [cluster/hub name] as a prefix, and update titles to be representative for the ticket as they come in. An example would be to update the title jupyterhub problem to [clustername/hubname] Failure to start JupyterLab by default, arrives to RStudio. Sometimes a cluster has a single hub, and then its obvious, othertimes its a hub in a shared cluster, then its nice to know what shared cluster its part of.
2. Provide summaries on what remains relevant by adding private notes, capturing remaining action points so anyone (including yourself) reading the ticket later can ignore the previous conversation easier
3. If we think a ticket is resolved, but is for example just pending confirmation that its resolved by the author - I've opted to mark it as resolved directly together with a private note on the status. It will re-open if a response arrives saying it is or isn't resolved by the author. This way, we reduce the open tickets to browse.
4. If a ticket is pending work tracked in github, it should be marked as pending together with a private note saying its pending resolution in linked github issue, and the github issue should be updated with an action point to follow up in this ticket. As part of marking it as pending, the ticket should not be used to track further things, and it can be good to convey that this ticket is now tied to that github issue, and they will receive a response here when its resolved.

Advice

• Let the home screen filter on a group, its a persistent personal choice. I see support + unassigned by selecting support.
• Use the "recent activities" link from the default dashboard top right corner to understand what has happened since your last checkin.
• When browsing tickets, use filters like this. In the link I'm filtering on the group support and unassigned to focus on support tickets, and I'm filtering on open tickets to avoid attending to pending tickets tracked by in github.
• Click on a username to see what tickets has been opened historitically, you can often learn what cluster/hub they are part of like that for example.
• If you are confused about what "LACC" refers to for example, its probably their hub name. Search for it in the 2i2c-org/infrastructure repo cloned locally and you will often be able to figure out cluster name / hub name.
• Use cluster.yaml files in 2i2c-org/infrastructure to figure out if a hub is GCP or AWS based, include this insights when relevant

[yuvipanda]

I followed most of these when handling https://2i2c.freshdesk.com/a/tickets/449 and it was helpful to me.

[damianavila]

Quick question for discussion, are we switching to pending ONLY if we create a follow-up GH? Or do we identify other "pending" states with the pending status? (ie. waiting for a reply from the community representative).

[consideRatio]

Pending discussion:

I think it can be pending for any reason that is very explicit with private notes. So, put something in pending -> ensure state is summarized and whoever reading that note understands the status and whats being awaited.

[jmunroe]

After meeting with Openscapes (2024-03-12) it was discovered that

1. community members appreciate being able to 'see' the GitHub issues that are tracking their requests
2. they don't always realize that these issue are being often being tracked in our publicly readable https://github.com/2i2c-org/infrastructure/issues repository
3. they really appreciate the transparency that 2i2c demonstrates in handling their requests
4. they sometimes feels that, with FreshDesk, the request is being 'hidden' and thus losing some of that transparency they had previously experienced

Proposal: When a GitHub issue to track a corresponding FreshDesk issue, we have gotten in the habit of cross-referencing GitHub as a 'private note'. Instead, when GitHub issue is created in a publicly accessible repository, we should put that information in a response so that the community has visibility as well as the 2i2c support team.

I suggest modifing @consideRatio suggestion to be:

4. If a ticket is pending work tracked in github, it should be marked as pending together with a public note saying its pending resolution in linked github issue, and the github issue should be updated with an action point to follow up in this ticket. As part of marking it as pending, the ticket should not be used to track further things, and it can be good to convey that this ticket is now tied to that github issue, and they will receive a response here when its resolved.