Skip to content

Require seniors to become maintainers

Michelle Gill requested to merge m_gill-master-patch-68871 into master

Why is this change being made?

As part of the maintainership working group, we are working to address our current maintainers being overwhelmed (taking the busy indicator off and being flooded with review requests, having no maintainers available for certain projects or regions, reviewing more than 100 MRs per month in some cases) while preparing for the future growth we expect (hiring growth, 700+% growth in contributions, new projects/services, process compliance changes.) Our exit criteria is based around making this process more efficient and easier to adopt without sacrificing quality.

With the improvements we are making in the working group, an increase in maintainers is still required:

  • ~20% of our 15.0 MRs had an element of being self-merged, which is a quality concern as well as a future compliance concern
  • Only 50% of our maintainers are available at any time - many of our maintainers also maintain other projects or have multiple specialties, in addition to our PTO spread being roughly 4 days per team member (Note: PTO number is not an even distribution)
  • 25% of our maintainers are reviewing between 41-115 MRs per month
  • In some projects, there are no maintainers who are able to approve MRs. This has blocked team members, delayed us from resolving production incidents, prevented us from having coverage during feature launches, and/or lowered quality further by allowing MR authors to merge their own code (a compliance concern) or pulling from existing maintainers in other projects (more review load.)

These circumstances result in our current review load being overwhelming, and it does not consider future growth.

Based on the availability we can expect from maintainers, the number of projects/areas they need to support, the number of incoming code review requests now and in the future, and what a reasonable number of reviews is per week - the first iteration is to increase maintainers by requiring senior engineers to become a maintainer in at least one project/area. Doing this sooner rather than later will spread the load and prevent being overloaded, which causes quality to suffer (production incidents, FCLs, etc)

Here is a slidedeck with more information

Who does this change impact?

Today, 89% of seniors (who have been at the company for 6 months or more) are already maintainers or trainees, and 51% maintain multiple projects. This change will impact the remaining 11%.

If a team member is not able to become a maintainer or has a personal reason for not being comfortable with this, please reach out to your manager or the Team Member Relations team to discuss aligned with our reasonable accommodation process.

What about the concerns already voiced about requiring maintainership?

There are numerous concerns which have been voiced in several issues (as part of this working group and in previous years). In a recent survey, 11% of respondents did not want to become a maintainer, and 35% disagreed that it should be a senior+ responsibility. There were 5 primary reasons based on this survey:

  1. Extra work load
  2. Context-switching
  3. Unfamiliarity / Inexperience in some areas
  4. Do not want the additional responsibility (potentially merging broken code)
  5. Scheduling and prioritization over Deliverables

The above concerns are taken seriously and all are being discussed as part of the working group as part of the existing exit criteria topics, but also more specifically in some issues:

Shouldn't we wait until the concerns are addressed before making this a requirement?

In short, I don't think we should or can. In the last 30 days, we have needed more 2,300+ backend maintainer reviews, 400+ database maintainer reviews, and 1,500+ frontend maintainer reviews. With our current maintainer numbers and what their availability is, this means multiple MRs to review each day per maintainer - and some maintainers doing more than 100 maintainer reviews a month. As the diff outlines, seniors are already required to be trainee maintainers in one of our listed projects.

There are 2 factors at play and we must address both. This MR only addresses one. Those 2 areas are - Increasing maintainers and Improving the process (review process, efficiency, requirements, so on.) This MR does not address improving the process, but the working group does and we will continue to iterate.

Timeline

  • Gather feedback until 2022-07-08
  • Address followups and prepare communications through 2022-07-15

Before merging this change

  • We will gather feedback to follow up on / include in the working group exit criteria
  • We will have a communication plan ready for impacted individuals and the wider department

Review App Links

Author Checklist

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
    • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.
Edited by Christopher Lefelhocz

Merge request reports