Considerations for changes to Trainee Maintainership

Trainee maintainership has long been an important milestone for many gitlab engineers. Recently, it was even decided that maintainership was a required step for any person seeking a promotion, and an expectation for any senior engineer.

I'd like to examine the benefits and drawbacks of the current system and then start a discussion in comments about potential alternatives or augmentations.

Current Process

High level Criteria

While each maintainer type has it's own requirements, the general guidelines are the same, someone is "ready" for maintainership when:

• The MRs they've reviewed consistently make it through maintainer review without significant additionally required changes.
• The MRs they've written consistently make it through reviewer and maintainer review without significant required changes.

And as general guidelines:

• In general, the further along in their career someone is, the more we expect them to be capable of becoming a maintainer.
• Maintainers should have an advanced understanding of the GitLab project that they wish to maintain. Before applying for maintainership, a person should get a good feel for the project codebase, expertise in one or more domains, and deep understanding of our coding standards.

Current Approval Process

The approval process to follow is:

• The MR will remain open for 5 working days. If more than half of the existing maintainers of the relevant engineering group (e.g. backend) approve the MR, and there are no blocking concerns raised during this period, we've got ourselves a new maintainer!
• If the MR does not have enough approvals after this period, and no blocking concerns, then the manager should mention the existing maintainers again in a new comment as well as in the relevant Slack channel (e.g. #backend) and keep the MR open for 5 more working days.
• After the extra period, any missing feedback from a maintainer should be counted as a neutral response and the manager can merge the MR given no blocking concerns were raised!
• Normal non-blocking feedback should be submitted as comments to the MR. To support Gitlab Values and avoid groupthink, any blocking negative feedback should be instead submitted to the manager of the aspiring maintainer. The manager will then share the feedback with the aspiring maintainer and post a generic message with a "TL;DR" in the MR.
• If there are blocking concerns raised at any point in the approval process, the maintainers who raised the concern should actively work with the maintainer nominee's manager to develop a plan on how to resolve the concern.

Pros and Cons

Pros

• The trainee process has routinely produced high quality maintainers worthy of the trust.
• The trainee process has been easy to extend for other types of maintainers, making it flexible across projects and maintainer types

Cons

• It takes a minimum of 6 months, and sometimes over a year for a trainee to become a maintainer
• Converting trainees to maintainers requires what amounts to a public vote of confidence
  • This can be daunting for folks who are nervous about putting themselves out there like that
  • This part of the process has been described as "hazing" by more than one member of the team
  • Trainees have reported "Optional" requirements sometimes hold them back because they believe they will prevent them from gaining maintainership
• Tends to lead us to have maintainers with similar opinions as existing maintainers
• Because the requirements are not concrete, engineers are uncertain about when they may qualify for maintainership

Call to Action

Take a moment to read through the process becoming a maintainer the pros and cons above and then add a comment with:

• Suggestions pros or cons you believe may be missing
• Suggestions that may help eliminate or reduce impact of Cons for our current system