Skip to content

Trainee Backend Maintainer (Gitlab) - Kasia Misirli

Basic setup

  1. Decide which project you would like to become a maintainer of.
  2. Change this issue title to include your name and project: Trainee Maintainer: [Your Name] ([Project]).
  3. Read the code review guidelines.
  4. Understand how to become a maintainer.
  5. Add yourself as a trainee maintainer in the team database.
  6. Mention a current maintainer of the project you chose to potentially act as your Maintainer Mentor during the traineeship.
  7. Mention your manager in this issue for awareness.
  8. Shadow a maintainer while they review an MR. This will allow you to get insight into the thought processes involved. (You may want to do this multiple times)
  9. Have a maintainer shadow you while you review an MR as if you were a maintainer . Ideally, this would be with a different maintainer to the above, so you can get different insights. (This is also worth doing a few times)

Working towards becoming a maintainer

This is not a checklist, but guidelines that will help you become a maintainer. Remember that there is no specific timeline on this, and that you should work together with your manager and current maintainers.

It is up to you to ensure that you are getting enough MRs to review. If you are not receiving enough MRs to advance in your training, be proactive and seek out opportunities for review. Maintainers are available to help guide you.

After each MR is merged or closed, add a discussion to this issue using this template:

### (Merge request title): (Merge request URL)

During review:
- (List anything of note, or a quick summary. "I suggested/identified/noted...")

Post-review:
- (List anything of note, or a quick summary. "I missed..." or "Merged as-is")

(@support-maintainer-username) please add feedback, and compare this review to
the average maintainer review.

Optional: Requesting recorded reviews for asynchronous learning

When handing off MRs to maintainers for final review, you may optionally ask if they'd be willing to record their review process. This can provide valuable asynchronous learning opportunities to understand maintainer-level thinking and decision-making patterns.

How to make the request:

  • Keep it genuinely optional and pressure-free
  • Example language: "If you have time and are comfortable with it, would you be willing to record your review process? It would help me learn asynchronously from your thought process, but no worries if not!"

Recording options for maintainers:

  • Private: Share recording directly with you for learning.
  • GitLab-only: Share within GitLab using the Merge request reviews playlist, but set to private.
  • Public: Consider making public on the GitLab Unfiltered playlist if comfortable, following GitLab's public by default guidance.

Remember: This is completely optional for maintainers. The goal is to create learning opportunities without adding pressure or burden to their existing review responsibilities.

Warning: For security MRs, no discussion should take place in the issue (even if using an internal note), as this might reveal security issue details. Instead, if you want to discuss the MR, you may create a discussion in the original MR, and link to it from a discussion in the trainee maintainer issue.

When you're ready to make it official

When reviews have accumulated, and recent reviews consistently fulfill maintainer responsibilities:

  1. Create a merge request updating your team member entry using one of available merge request templates proposing yourself as a maintainer for the relevant application.
  2. Follow the instructions in the merge request template
Edited by Kasia Misirli