Integrations support rotation
Note: This processes is currently in trial mode, meaning we will re-evaulate the value it brings on Nov 21 (~2 months after the introduction).
The Integrations team has a dedicated member on a weekly support rotation. This document outlines the responsibilities of this role and how to execute the tasks. In a nutshell, these are the responsibilities of the engineer:
- Respond and triage incoming inquiries from other teams and the support channels
Expectations
The engineer on rotation is expected to comply with these responsibilities only within their usual working hours. There is no on-call, 24x7-watch expectation on these tasks. The async nature of Sourcegraph allows us to properly support the organization without having to be in front of the computer all day.
We do not expect work related to the support rotation to take up more than 10% of your time while on schedule.
You are not expected to provide all answers to inquiries or review all PRs. You are expected to be the initial responder and decide whether to tackle the work right away or add it for later planning. As a general rule of thumb, any work that will take longer than two hours should become an issue in the team’s GitHub board. This also includes work that takes less than half a day but needs to be transitioned to another engineer.
The engineer on support rotation is responsible for anything that doesn’t have a clear owner in our team. For example if we start receiving a trove of PRs for something that another engineer is currently working on, there’s no need to keep an eye on those. On the other hand, if it’s a one-off review then it’s your responsibility to ensure the ball doesn’t get dropped.
Finally, it’s your responsibility to ensure a smooth transition to the next engineer on rotation. This includes:
- Wrapping up tasks as you can
- Ensuring all tasks are properly documented (with GitHub issues and status updates)
- Communicating any leftover tasks/asks/things to keep in mind for whoever is up next. This is best done the day before the rotation transitions via an async recap update posted in
#integrations-internal
.
Guidelines on priorization
The Integrations project board defines a priority column with four priorities:
- 🚨 Critical
- 🔴 High
- 🟡 Medium
- 🟢 Low
However, there is currently no definition of how to assign these priorities so you are encouraged to go with your gut feeling and best effort.
Channels to keep an eye on
The following channels/boards should be checked at least once a day:
- #integrations
- #integrations-internal
- #integrations-ide
- #alerts-integrations
- #feedback-dogfood
- Messages that tag
@integrations-team
or@integrations-eng
- GitHub notifications tagging
@sourcegraph/integrations
- GitHub issues that tag
team/integrations
.
If you’re curious, here’s a work-in-progress list of all channels that support tickets can come from.
Why we are doing this
This process was first discussed as a suggestion to improve how we handle feedback in our team during the 2022 Barcelona team offsite.
We believe this process has the following benefits:
- Engineers have easier exposure to all areas that the team owns (everyone will eventually see BExt, VSCE, JB and other bugs). This will also help with onboarding new engineers.
- We can rely on incoming feedback being responded to, so others have piece of mind and can focus on their work.
- We have an explicit time budget so the person on support rotation knows that they will have the time to work on triaging.
- We can set up SLAs on various channels.
Current schedule
Time frame | Engineer |
---|---|
Sept 26–Oct 3 | Philipp |
Oct 3–Oct 10 | David |
Oct 10–Oct 17 | Taras |
Oct 17–Oct 24 | Beatrix |
Oct 24–Oct 31 | Philipp |
Oct 31–Nov 7 | David |
Nov 7–Nov 14 | Taras |
Nov 14–Nov 21 | Beatrix |