Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require support tickets to be *initiated* by community reps #797

Merged
merged 4 commits into from
Feb 2, 2024
Merged

Require support tickets to be *initiated* by community reps #797

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f5ff4ae
Require support tickets to be *initiated* by community reps
yuvipanda Jan 23, 2024
cd53853
Cleanup step reference numbers
yuvipanda Jan 30, 2024
eab17ce
Fix missing space
yuvipanda Jan 30, 2024
ecbf059
Merge branch 'main' into authorized
GeorgianaElena Feb 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 39 additions & 20 deletions projects/managed-hubs/support.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,19 +179,38 @@ The current iteration of the workflow states each step and who should be respons

When a new ticket lands in Freshdesk under the support group and it is not an incident, we aim to respond within 24 working hours with a suggested next action. The next steps should be followed when resolving a ticket:

1. `Who: Support steward`
1. `Who:Support steward`
yuvipanda marked this conversation as resolved.
Show resolved Hide resolved

**First 24h initial ticket evaluation**. In the first 24h a support ticket was opened, you should do an initial evaluation of the ticket and ask the {term}`Community Representative` about any additional information you may need.
First, we determine if the person *initiating* the support ticket is *authorized* to do actually do so. While we may interact with many folks
yuvipanda marked this conversation as resolved.
Show resolved Hide resolved
from a community during resolution of a ticket, we constrain who can *initiate* a ticket to {term}`Community Representative`s only. This prevents our
support staff from being overwhelmed by tickets that need to be handled elsewhere. If the person *initiating* the ticket is not a community
representative, the support steward should cc the community representatives, and ask for approval. The support steward *may* choose to use the following
email template:
yuvipanda marked this conversation as resolved.
Show resolved Hide resolved

> Hello <names of community representatives>,
>
> I'm cc'ing you on this support ticket we received from a member of your community. To streamline our support process, 2i2c is accepting
> support requests only from communtity representatives. Can you read through the request, and let us know how you wish to proceed?
yuvipanda marked this conversation as resolved.
Show resolved Hide resolved
>
> Thanks.

You can use [this airtable](https://airtable.com/appxk7c9WUsDjSi0Q/tbl3CWOgyoEtuGuIw/viwtpo7RxkYv63hiD?blocks=hide) as the *source of truth*
for who can initiate support requests for which communities. You should find the username & password for 2i2c airtable account in the organizational
bitwarden.

2. `Who: Support steward`

**First 24h initial ticket evaluation**. In the first 24h a support ticket was opened, you should do an initial evaluation of the ticket and ask the {term}`Community Representative` about any additional information you may need.

3. `Who: Support steward`

**Spend 30 minutes trying to resolve**. If you believe you can resolve the issue within 30 minutes, try resolving it yourself.
1. If you resolve the issue, then jump to the "Confirm resolution" step 7.
2. If you don't believe you can resolve the issue (or you couldn't) in 30 minutes, jump to the next step.

Follow the guide at [](support:timeboxed-evaluation) to try and reach to a decision.

3. `Who: Support Steward`
4. `Who: Support Steward`

**Open an issue in the 2i2c/infrastructure repository**. If this is an issue that cannot be resolved within 30 minutes, then open a GitHub issue for the team to discuss.

Expand All @@ -200,39 +219,39 @@ When a new ticket lands in Freshdesk under the support group and it is not an in
This issue will then be automatically added to the **Eng & Prod** board by the existing automation alongside the the **type**: `support` and the **impact** level specified in the form project fields.

If the issue has a `critical` impact (we defer that first evaluation to the support steward), an additional ping to the support Slack channel is needed to boost the signal.

:::{admonition} What does `critical` mean?

We recognize there might be some support-related issues that do not count as [incidents](incidents:what), but
they need a quick resolution (inside the current sprint window) because they are impacting the execution of
We recognize there might be some support-related issues that do not count as [incidents](incidents:what), but
they need a quick resolution (inside the current sprint window) because they are impacting the execution of
desired or existing workflows (degraded experience) for our communities.
Examples of those sorts of issues (requests) are:
* Image refs updates
* Profile updates
* User storage limitations
* Grafana (and Prometheus) failures

Additionally and depending on the nature AND context of the issue (request):
* Access to specific buckets
* Authentication and authorization updates
:::

The support steward **should** self-assign the `critical` issue and work on it immediately (this is now outside of the 30-minute timebox described in step 2).

If the support stewards (both of them) do not have the capacity to resolve the `critical` issue (ie. working on another `critical` issue, being out of their working time, etc.), they should ping the **Engineering Manager** (or the delegated person) so they can secure resources to resolve that issue on the fly (see step 7 below).

The support steward **should not** work on issues with impact lower than `critical` (unless they are assigned as part of the "planned" reactive work in the context of a running sprint (see step 6 below).

4. `Who: Partnerships representative and the Engineering Manager (or respective delegates)`
5. `Who: Partnerships representative and the Engineering Manager (or respective delegates)`

**Revisit the impact metadata**. Once a week (at minimum) the [support view in the **Eng & Prod** board](https://github.com/orgs/2i2c-org/projects/22/views/47) should be revisited to validate the impact level on support-related issues. Currently, we allocate a 30-minute working session every Wednesday (open to everyone to participate) to perform such impact revision and further prioritization ("planned" reactive) every other week (see step 7 for more details).

5. `Who: Support steward`

**Add a reference/link to the created engineering issue inside the Freshdesk ticket**. You can use an internal note or make it public when you communicate back to the Community Representative in step 6. Also, move the status of the ticket to the "Pending" state.

6. `Who: Support steward`

**Add a reference/link to the created engineering issue inside the Freshdesk ticket**. You can use an internal note or make it public when you communicate back to the Community Representative in step 6. Also, move the status of the ticket to the "Pending" state.
yuvipanda marked this conversation as resolved.
Show resolved Hide resolved

7. `Who: Support steward`

**Communicate status**. Once we have an issue created to track the next steps, send a message to the Community Representative letting them know about the situation: after some initial investigation and no immediate fix, a follow-up issue was created that will be assigned in the future accordingly to the current prioritization. Also, let them know what the next steps will be. Here's a template to help guide you:

```
Expand All @@ -242,23 +261,23 @@ When a new ticket lands in Freshdesk under the support group and it is not an in
when we've got a plan for completing this request.
```

7. `Who: Engineering Manager (currently assigning reactive work) or someone delegated by the Engineering Manager`
8. `Who: Engineering Manager (currently assigning reactive work) or someone delegated by the Engineering Manager`

**Prioritize the request**. Any non-`critical` issue should wait to be included in our sprints (on Wednesdays, every other week) to be worked out as part of the "planned" reactive work. Follow the [how to prioritize Change and Guidance Requests guide](support:prioritize-requests) to decide how we should prioritize this request relative to the other work we need to do. We should be fully transparent about the support queue to our Community Representatives if they ping us for updates.

If there is any `critical` issue, we could assign people on the fly (during the sprint) to resolve them, but we should minimize that behavior (it should be exceptional cases).

8. `Who: Support steward`
9. `Who: Support steward`

**Resolve the request**. When some engineer is assigned to a support-related GH issue in the context of a sprint, we move ahead with the investigation/resolution for one (1) sprint. If we failed to find a fix during that time, we communicate back that state in the Freshdesk ticket and resolve it.

Exceptional tickets might need more than one sprint. These tickets need to be explicitly approved as exceptions.

9. `Who: Support steward`
10. `Who: Support steward`

**Confirm resolution**. Once we have resolved a support request, send a message to the Community Representative to confirm that we believe it is resolved. In FreshDesk, mark the incident as {guilabel}`Resolved`.

10. `Who: Support steward`
11. `Who: Support steward`

**Close the request**. If the Community Representative confirms that their request has been fulfilled, consider this request closed. In FreshDesk, mark the incident as {guilabel}`Closed`.

Expand Down