Switchboard team

Summary

Switchboard is a team within the Dedicated Group. Our mission is to empower external GitLab Dedicated customers to manage their tenant environments and reduce the operational overhead on the Environment Automation team so we can scale up the GitLab Dedicated offering. We follow the same processes as listed on the the Dedicated Group, unless a difference exists which is explicitly noted on this page.

Resources

• Switchboard Direction Page
• Switchboard Demo Library

Team Members

Name	Role
Amy Shiel	Engineering Manager, Dedicated:Switchboard
Andrey Ruzmanov	Senior Backend Engineer
Graeme Gillies	Senior Site Reliability Engineer, Dedicated:Switchboard
Lekan Sogunle	Senior Backend Engineer
Marina Mosti	Frontend Engineer, Infrastructure
Sean Arnold	Senior Backend Engineer, Dedicated:Switchboard

Product Manager: Loryn Bortins Technical Writer: Lysanne Pinto Product Designer: Divya Alagarsamy

Working with us

To engage with the Switchboard team:

• Create an issue in the GitLab Dedicated team issue tracker

• Label the issue with:

  • component::Switchboard
  • workflow-infra::Triage
  • team::Switchboard

• When creating an issue, it is not necessary to @mention anyone

• In case you want to get attention, use a specific team handle (Ex: @gitlab-dedicated/switchboard ) as defined in Dedicated group hierarchy

• Switchboard issue board tracks all of the team’s current work

• We are in the process of adapting to use the Product Development Flow

• Slack channels

  • For Switchboard specific questions, you can find us in #g_dedicated-switchboard-team
  • Our Slack group handle is @dedicated-switchboard-team
  • Other teams in Dedicated group have their own work channels for team work discussions:
    • #g_dedicated-team
    • #g_dedicated-us-pubsec

Requesting Access to the Switchboard application

• Create an Access Request specifying
  • the specific environment ( Test / Beta / Production )
  • level of access required (Readonly, Support, Provisioner, Operator)
  • justification for the access
• Access & Provision Details for the application can be found in the Switchboard - GitLab Dedicated section of the Tech Stack

How we work

Meetings and Scheduled Calls

Our preference is to work asynchronously, within our project issue tracker as described in the project management section.

The team does have a set of regular synchronous calls:

• Switchboard Sync - During this call, we are sharing important information for team-members day-to-day, as well as project items requiring a sync discussion
• 1-1s between the Individual Contributors and Engineering Managers

Impromptu Zoom meetings for discussing Switchboard work between individuals are created as needed. It is expected that these meetings are private streamed, or recorded(1*), and then uploaded to GitLab Unfiltered playlist. The outcome of the call is shared in a persistent location (Slack is not persistent). This is especially important as the team grows, because any decisions that are made in the early stage have will be questioned in the later stages when the team is larger.

1* Exceptions to the recording rule are: 1-1 calls, discussions around non-project work, and in cases where parties do not feel comfortable with recording or we cannot record due to the nature of content discussed. However, even with the exceptions, outcome of project related discussions need to be logged in a persistent location, such as the main issue tracker.

Tracking & Planning Work

Resources

• Switchboard team roadmap
• Switchboard team top-level epic
• Switchboard team issue board
• Switchboard technical writing board
• Dedicated Issue Tracker

Quarterly Planning

Quarterly planning is owned and driven by the Switchboard EM and PM.

1. EM or PM creates a quarterly planning issue using the Dedicated quarterly_planning issue template.

   • Set the issue title to Switchboard - FYXXQY planning where XX is the year and Y is the quarter
   • Ideally planning should be kicked off at least a quarter in advance. The planning issue for the upcoming quarter should be created on or before the first day of the second month of the current quarter

2. EM & PM brainstorm asynchronously on the issue

3. During month 3 of the current quarter EM or PM

   • Reach out to the team for input
   • Ensure all dependencies are communicated with the relevant teams
   • Prioritise the objectives
   • Document the associated epics

4. EM creates a delivery epic for the quarter that will be used in Grand Reviews and updates the epic-summaries bot to reflect this change

Epic Refinement

Switchboard team process to refine epics:

1. Identify a DRI for the epic
   • Team members can volunteer or the EM may ask team ask specific team members to act as DRI
2. Identify any missing requirements
   • All team members ask questions in the comments of this issue to drive out any edge cases
3. DRI labels the epic as ~“workflow-infra::Ready”
4. DRI ensures Epic Kick-Off is complete - see Epic Template
5. Assign Due Date & Start Date
   • DRI, EM & PM work together to assign due date based on team capacity, external deadlines and amount of work involved
6. DRI identifies at least one demo that will be delivered with the epic and adds a brief outline to the epic description (see Switchboard Demos).
7. EM or DRI labels individual issues as ~“workflow-infra::Triage”
8. DRI enables issues to be worked on in parallel where possible so that multiple engineers can contribute to a single epic
9. If the epic involves both Frontend and Backend implementation the issues should be labelled accordingly
10. Team members pick up issues and start working on them
11. Team members use Progress Threads to track progress in individual issues
12. Team checks in on progress during Switchboard Sync
    • Any epics with no issues to raise can be read-only
    • Priority given to discussions of epics based on soonest due date
13. If due date is not realistic team member comments on the issue as early as possible so that the team can work together to address this

Note 1, 2 & 4 can be carried out in parallel

Issue Refinement

Switchboard team process to refine issues:

1. When an issue is created and ready to be refined it is labelled ~“workflow-infra::Triage”
2. PM and EM ensure that the Open and ~“workflow-infra::Ready” columns are prioritised
3. Team members look at issues in the Open column of the issue board and ask questions on the issue to drive clarity
4. When there are no outstanding questions on the issue it can be labelled ~“workflow-infra::Ready” and it will automatically move into the Ready column
5. If the issue exposes text to users in any way the technical writing label should be added. For example if the issue changes UI text, shows an error message, adds a field etc
6. If the issue requires Frontend implementation the frontend label should be used
7. DRI enables issues to be worked on in parallel where possible so that multiple engineers can contribute to a single epic
8. The default is to keep both frontend and backend implementation for a single piece of functionality on the same issue so that discussions are centralised, implementation is carried out in parallel and frontend and backend engineers are in sync
9. Frontend and backend implementation should be delivered in separate MRs
10. If the implementation cannot be done in parallel, or there is a likely to be a meaningful delay between backend and frontend implementations, or if the backend can deliver value independently the issue should be split and the relationship clearly identified by linking the issues

Issue & Epic tracking

1. Engineers use Progress Threads to share progress in an async fashion
2. At the beginning of the Switchboard Sync the team will check in on epics labelled ~“workflow-infra::In Progress” or ~“workflow-infra::Triage” to ensure due dates are appropriate and highlight any blockers
3. Epic DRIs update the status in the Epic Description every Wednesday in preparation for the Grand Review
4. Epic DRIs review the due date weekly. The epic status update should include the DRI’s confidence level in the due date and any risks to delivery

Picking up work / What to work on next

1. ~“workflow-infra::Ready” column on the issue board

   1. Pick an issue from the ~“workflow-infra::Ready” column on the issue board
   2. Assign the issue to yourself and set to ~“workflow-infra::In Progress”
   3. Update the issue description with an Implementation Plan where relevant
   4. Create a Progress Thread on the issue and update daily

2. Switchboard team top-level epic

   1. Look at the Switchboard top level epic and offer to work on issues with the nearest due date
   2. Use the Switchboard team roadmap for guidance

3. Open column on the issue board

   1. Look at the issues at the top of the Open column
   2. For each issue ask questions and drive a discussion to identify any missing information
   3. Mark the issue as ~“workflow-infra::Ready” if it is ready to be worked on or @mention the EM if you are not confident to do so

Switchboard Demos

A demo enables a team member to share progress or the final output of an issue or epic. The focus is on sharing information, not creating an oscar winning documentary, so as a team we use the boring solution of either a screen recording, a recorded Zoom meeting or Loom. A link to the recording is added to the epic description.

The epic DRI is responsible for identifying at least one demo that will be delivered with the epic when the epic is being kicked off. For example When the functionality x is delivered (or issue y is Done) we will demo functionality x. Team members are encouraged to time demos to be delivered shortly before the fortnightly Switchboard Team Syncs whenever possible so that any synchronous Q&A can happen during already reserved time. Team members may choose to create additional demos to share progress or delivery milestones.

Issue Templates

Switchboard maintains the following issue templates:

Merge Request Review Guidelines

We specifically adhere to the GitLab Code Review Guidelines and follow the Dedicated group principles when requesting merge request reviews.

Merge request review process

As the Switchboard team is currently small, we use an ‘Approve and Merge’ approach:

1. When you’re ready to have your merge request reviewed, select one or more Switchboard reviewers.
   • If you’re not certain about who to choose, you can use the reviewer roulette to randomly select a reviewer.
   • If the issue is labelled technical writing add the Switchboard technical writer as a reviewer
2. Reviewers will perform a review based on reviewing a merge request guidelines.
3. If satisfied, a reviewer will approve and merge unless other reviewers have questions or suggestions that are not addressed.
4. If the merge request contains the required approvals, the reviewer will trigger a pipeline and set auto-merge.
   • If the reviewer does not have merge permission, they should seek out a maintainer for merging.

Additional UI Review Process

In addition to the above when a change is being proposed to the UI the following extra steps should be followed:

UI changes visible to internal GitLab users:

1. MR author cc’s PM & UX Designer on the MR but they are not reviewers or blockers of the merge
2. If they have any suggestions they can be dealt with on the MR or on a later MR at the MR author’s discretion
3. Eventually the PM & UX Designer will be reviewers on the internally visible UI updates but our process is not there yet nor is their capacity
4. If you require help or guidance with the UX or copy please ask before implementation begins on the issue

UI changes visible to external customers:

1. Figure out any outstanding questions on the issue, including copy changes, so that we can avoid ambiguity at the MR stage
2. The PM and Designer will deal with these requests as a top priority
3. Add the PM as reviewer on the MR. This review will be blocking the MR and the PM will deal with this a high priority
4. If there is new copy add the Technical Writer as a reviewer and this will be blocking (copy should ideally be agreed on the issue)
5. Cc the UX Designer on the MR and when they ready to be core reviewer this will be communicated to the team

Note: If significant discussion ends up being needed for a UI change (internal or customer facing) after the MR has been opened, that discussion should be moved back to the issue to resolve and the MR marked as blocked. These discussions will be high priority to resolve and the issue should be assigned to the PM and Designer until progress on the MR can resume. Notes:

• It is our intention to move towards a typical ‘reviewers and maintainers’ approach which would require two reviews as soon as we have the team members to support this.
• Merge requests should be approved based on the approval guidelines.
• As per the GitLab Review Guidelines there are scenarios where it is appropriate for the author to merge the merge request: If there are no blocking comments, and the merge request has all the required approvals, the author or maintainer can merge.
• Switchboard project is configured to use pipelines for merged results which means that reviewers need to run a pipeline pre-merge to guarantee that updates are compatible with the latest main branch.
• When reviewing merge requests, reviewers should use the Conventional Comment labels to convey your intent.
  • For the avoidance of doubt Suggestion:, Issue: and Chore: comments are all blocking, unless decorated with a (non-blocking) statement.
• We label merge requests using the Specialization labels found in the GitLab documentation. MRs should be labelled ~“frontend”, ~“backend” or ~“documentation”

Approval guidelines

Reviewer roulette

Reviewer roulette is an internal tool for use on GitLab.com projects that randomly picks a maintainer for each area of the codebase. To select a maintainer:

1. Go to the reviewer roulette page.
2. Select the Switchboard project.
3. Choose the desire role: ~maintainer::frontend, ~maintainer::backend, ~reviewer::backend, ~reviewer::frontend.
4. Click on Spin the wheel.

GitLab Code Review Guidelines

• Having your merge request reviewed
• Reviewing a merge request
• The Right Balance
• Quality
• Performance, reliability and availability
• Merge request performance guidelines

Reviewers and maintainers

There are two groups for Switchboard, Reviewers and Maintainers:

• All Switchboard team members are included in the Reviewer group.
• When a team member is fully onboarded and feel confident in their knowledge of the codebase they are invited to the Maintainer group.

Epic Template

DRI:

### Participants
*

### Problem to solve

Video Walkthrough from Product:

### Intended users


### User experience goal


### Proposal


### Open Questions


### Further details


### Permissions and Security


### Documentation

* Publicly Accessible Documentation:

### Epic Kick-Off
* [ ] Video walkthrough from Product outlining expectations
* [ ] DRI identified
* [ ] Roll out plan agreed
* [ ] External customer communication plan defined
* [ ] Copy Requirements are hightlighted to the Technical Writer
* [ ] UX Requirements are highlighted UX Designer
* [ ] Issue created to track Documentation requirements
* [ ] Outstanding Questions captured in threads for resolution

### Roll out Plan

<!--
If visible to external customers please provide the following information:
    - What communication is required ahead of release?
      - [ ] Internal communication to account teams
      - [ ] Customer communication in release post
      - [ ] Sign off from account teams before release - this should be reserved for features with the potential to be disruptive to users
    - Will this be rolled out to customers in pieces as implemented or available internally first?
-->

### Links / references

*

### Demo Description

Demo Link - see https://handbook.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/switchboard/#switchboard-demos

---

### Status YYYY-MM-DD

1.

<details>
<summary>Previous status updates</summary>

### Status YYYY-MM_DD

1.
</details>

/label ~"team::Switchboard" ~"workflow-infra::Triage"

View page source - Edit this page - please contribute.