Skip to content

Expand TW onboarding process and template

Marcel Amirault requested to merge update-onboarding-reviewers into main

I have several suggestions for improving TW team onboarding:

I noticed the last few months that our new TWs do not show up in the Workload Dashboard at all while they are onboarding. In this onboarding issue, we do tell them to add themselves as maintainers (by updating their team file), but not until they are basically finished onboarding completely (when they get maintainer access).

I feel this is too late. When I started (a long time ago in a galaxy far, far away), we initially became reviewers, then later maintainers, which is very similar to the process for engineers. For example:

I think we should resurrect this process, which gives us an intermediary step between start -> fully onboarded maintainer.

The process should look like this:

  1. Go through and complete "basic" TW team onboarding steps (handbook, guidelines, Git/GitLab practice with a test project).
  2. Start shadowing your buddy's work and learn the process/skills. Your buddy/coach assigns you reviews to help you learn.
  3. Start onboarding into your groups by reading all the docs, meeting team members, etc.
  4. Key change Become a reviewer for all the documentation projects, and review MRs for your new groups (with TW help as needed). You cannot merge, but you are recognized as a reviewer and show up in https://gitlab-org.gitlab.io/gitlab-roulette/. It also shows up in your profile that you are a reviewer for the various projects.
  5. MRs can now come to you directly from your groups, not assigned by your buddy/coach, but you still need a buddy/coach/other TW to merge. You can start to learn how to manage your workload through status updates, communicating with the groups, etc.
  6. When ready, you gain maintainer rights, submit an MR to change from reviewer to maintainer, and begin to lead your group solo.

A huge benefit to this is that when other TWs are looking for someone to review their self-authored work, they'll be able to see the newer members in the list and think "Oh, this is a good MR that highlights some detail that a new TW should learn about. It's not time sensitive, so I'll send it to them for first review."

Also, while here, I added:

  • Assorted copy edits.
  • Instructions to create a test project in the team's new group. A safe place to test features is something we should suggest early on, so people can tinker whenever they want.
Edited by Marcel Amirault

Merge request reports