Write proposal for support steward/triager responsibilities, and processes

[pnasrat]

Context

Write a proposal for the team to review that for improvements to the current support steward process and responsibilities.

The document will include trade-offs and consolidate various proposals or discussions in slack - including.

• Rotation process
  • Scenario I: 2-person team with 15 days rotations doing triage at 50% of your time.
  • Scenario II: 1-person team with 15 days rotations doing triage at 100% of your time.
• Renaming support steward role to triage
• Well defined hand-off process

Updated

Rationale: Our support process is homegrown and could use a bunch of tweaks now that we are not as resource-constrained as we used to be. The goal is to evolve the process to fit us better. The goals to be kept in mind are two-fold:

• Protect people in this role from burning out
• Protect others in the team from being interrupted constantly by external triggers.

Proposal

Definition of done:

• [x] Change the rotation duration and pattern: https://github.com/2i2c-org/team-roles-geekbot-sweep/issues/164
• [ ] #706
• [ ] Build a triager/support steward checklist
• [ ] Create an example canned response for one common issue
• [ ] Simple reporting about time involvement and ticket numbers in a rotation
• [ ] Consider being more specific about whether only routing is to be done, or routing + fixing, or whatever combination thereof. Consider changing the name to match too.
• [ ] Define, agree on, and document the escalation process (including communication aspects of the escalation process)
• [ ] Define knowledge base to pick up context

Updates and actions

No response

[pnasrat]

This is still being drafted but wanted to share early

https://hackmd.io/@pnasrat/BJuneLMCo

[GeorgianaElena]

I really like your proposal @pnasrat, and I especially appreciate all the research and thought put into it <3 Thank you very much.

Since I won't be able to participate to today's strategy meeting that will probably be about this proposal, I will put my (not very structured) thoughts async here (and in the agenda):

Personal choice

I would personally choose Scenario III: 2 1-person teams grouped by TZ with 15 days rotation in the draft proposal because:

• the triager will also need to be the person watching out for incidents being reported through tickets
• most of the hubs get to see lots of activity during the US tz and this is when tickets like "I have a class in 2 hours and this is not working" tend to appear. If only one person is activeley watching freshdesk, and that person is on the EU tz , then this might get undetected.

Idea?

With the above in mind and with the thought of trying to avoid night shifts as much as possible, maybe we can also consider a 4th scenario where we have a team formed by a triager (scenario II) + tz guardian. Where the tz guardian, is a person that just watches for time sensitive tickets on the tz opposite to the tz of the triager.

Handover

I believe something really low effort in the beginning would be to generate a triager's activity using Freshdesk's dashboards and filtering. For example this would be the link to the list of tickets that were resolved in the last 24h. And we could have many "reports" like that that could summarize what happened during a shift.

Misc

1. I strongly believe that in this iteration we need some support template responses or something that can be referenced like a guide and copy-pasted into a response for a quick first iteration.

First thing I that comes to mind right now is to formalize what each of the responsibilities mean and how they translate into a response. For example, when responding the first time to a ticket one needs to:

• let the sender know a human being noticed their ticket and works on it
• make sure the hub + cluster being referenced is clear enough (sometimes you need to infer this info from their email addresses)
• check if this is an urgent request or what is the timeline they have in mind etc...

Purpose of this iteration

2. I would really want us to work on creating a FAQ during this support iteration as proposed in https://github.com/2i2c-org/infrastructure/issues/2131. Personally, this is the outcome I envision for this iteration.

   I believe that having a FAQ and some standard response template, will allow us to decouple the engineer and triager role.I envision the engineer team to be the one tackling the GitHub issues and solve the incidents that get triggered after a different role or team triaged them and got enough info from the users to be turned into an actionable item.

[sgibson91]

I strongly believe that in this iteration we need some support template responses or something that can be referenced like a guide and copy-pasted into a response for a quick first iteration.

I strongly support this. 90% of my stress while on rotation is "oh god, what do I say/do?!" I don't want to be agonising over whether I have recommended the right thing.

[pnasrat]

Thanks @GeorgianaElena and @sgibson91 - yes templated responses is a huge stress reducer, and reports are super useful. I'm going to revise my proposal a bit taking on feedback from the Strategy and Organization meeting, and there are more notes from the meeting discussion in the running notes doc that I'll make a start incorporating once I've done the initial revisions.

[pnasrat]

Will be revisited as part of Q2 goals led by @damianavila

[damianavila]

Status update:

• We have several working sessions with @pnasrat, some notes collected at https://docs.google.com/document/d/1J-qkHJPTrw8uWcyexcJaBW83RHYFIQ5r3cCxRszhOzI/edit#heading=h.k6y0jlh7avnf
• @sgibson91 is going to join me on this goal for the rest of the quarter to help me move it forward.

I will create a meeting for both of us to get her up to date with the already discussed in the working sessions and get her input on the outlined plan. Then she will help me with operational tasks inherited from the proposal (once we get enough feedback from the team on moving it forward).