Require seniors to become maintainers
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:
- Extra work load
- Context-switching
- Unfamiliarity / Inexperience in some areas
- Do not want the additional responsibility (potentially merging broken code)
- 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:
- Should we consider adjusting capacity based on ... (#13413 - closed) works towards concerns 1, 2, 5 where we want to make sure being a maintainer and an engineer working on their product area are both in balance
- Improve the Trainee Maintainer process to make ... (&1814 - closed) works towards concerns 3, 4 where we want to reduce the barrier to entry on becoming a maintainer while still making sure trainees feel confident and prepared
- Review maintainer duties/requirements and imple... (#13311 - closed) works towards concern 4, where we want to reduce maintainer duties and clarify what the responsibilities are and are not
- How do we handle the "bursting" of maintainer r... (#13352 - closed) works towards concern 1 where we want to better distribute the workload among maintainers and prevent any small group of maintainers from being too overwhelmed
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
- Senior+ Maintainer page
- Senior backend job family
- Senior frontend job family
- Senior fullstack job family
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 DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
-
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.