This <name> team covers a wide range of the functionality and feature sets. Due to this you might find it necessary to reach out to ask us questions, get our review on a PR or an issue, or to simply say hello. In a way to minimize context switching and allow for everyone to focus on their tasks and project priorities, the team takes weekly shifts as a first responder. Also referred to as FR. The volume of incoming issues and requests will vary from week to week, so the primary focus of the FR is to ensure we effectively take care of incoming requests and issues so that everyone can be more productive.
The <name> team has rotations managed by PagerDuty schedules.
Our teams organize based on projects and areas of responsibility. The team maintains the <features> and <services>.
The team's manager @ssebelius will be identified as the escalation path and is available in an urgent situation if there is no answer from the Team First Responder.
Our FR responsibilities include:
- Helping run and taking notes for our weekly team sync meetings
- Responding to pings to the @team in a timely manner
- Responding to issues in our repo in a timely manner
- Responding to pagers & any SLA/SLO observability issues
The first responder responsibilities begin after the weekly sync and ends at the next weekly sync. The last thing the FR is expected to do is open the next weekly issue using the
For most issues or incoming requests we strive to have an SLA for a response within 24 hours. The response could vary from creating a new prioritized issue, completing the request, answering a question, or an acknowledgement and expected turnaround date for a resolution.
Not all types of requests are created equal and the first responder is there to ensure that each one is handled effectively. The First Responder will help by evaluating whether or not an issue, bug, support request, or question is suited for the team and determine how best to answer it.
Once an issue has been determined that it lands within a teams specific area of responsibility. The next step is to understand any issue or requests visibility, impact, and effort. By doing so, it helps prioritize and bucket any new work that the team might need to handle. It's important to know that the FR responsibility is not to immediately fix and handle everything themselves, but to help evaluate incoming requests so the the entire team can be engaged.
| Visibility | Impact | Effort | Priority |
|---|---|---|---|
| High | High | High | 1 |
| High | High | Low | 1 |
| Low | High | Low | 2 |
| High | Low | Low | 2 |
| Low | High | High | low |
| High | Low | High | low |
| Low | Low | Low | low |
| Low | Low | High | low |
- Visibility: Does this affect a lot of users (High), or only a few (Low)?
- Impact: Is this issue quite severe when it does occur (High), or is it fairly minor (Low)?
- Effort: Will this issue take a lot of time/resources to fix (High), or can it be addressed quickly and easily (Low)?
Useful information to help determine priority and effectively triage
- Is there enough information in the issue?
- Can you add information as to the visibility or impact?
- Can this issue be reproduced, are there steps?
- Is there a link to lines of code that may be useful?
- Are impacted users large clients or influencers?
When handling triage it is important to make sure we balance and weight the impact, visibility, and effort of any issue.
- 1: This is a high priority issue and will take priority over project and maintenance work.
- 2: This is important work that takes priority over bug fixes, non-critical technical debt, or any maintenance work.
- Low: Low priority work that does not take priority over maintenance or bug fix work and will be addressed as it is prioritized at a later weekly team sync meeting.
All new, non Priority 1 issues will be labeled with the appropriate label and placed into the triage board for the team to discuss at the next weekly meeting. At the weekly team meeting the first responder will discuss items in the triage queue and work with the team to prioritize for work, place into the project backlog, or icebox for later review.
Sometimes an inbound work item isn't high priority, but the level of effort to address it is small. In these cases the first responder can choose to work on this item in parallel with their current project commitments.
In the event you can't get the right answer, we're not able to respond, or the request is urgent you can find us in our slack channel and the first responder will be listed in the channel topic.