Maintainership

Attributes

Property	Value
Date Created	2022-04-19
End Date	2023-02-02
Slack	#wg_maintainership
Google Doc	Working Group Agenda
Task Board	Issue board
Epic	Link

Business Goal

We have seen overall inconsistent results with maintainership in the last quarter. Examples: A subset of maintainers are taking the burden of reviews which can lead to serious problems in job satisfaction issues and burnout. We are growing (both in headcount as well as community contributions), but the number of maintainers has stabilized. The number of repos which need maintainer support is increasing while coverage of them has decreased. We want transparency that seniors who are maintainers are having a positive impact in the multiple areas listed here, which leads to more career opportunities for them than it does non-maintainers.

Our objective is to change our processes and culture to have an organization which we know can sustain maintainership for the next 5 years that meets the demand of both the company and the open core project. This includes, but is not limited to:

• Increasing current maintainers and having a forecasting to know we will increase in the future.
• Availability measures which demonstrate maintainers are able to meet demands of code reviews
• Load balancing measures to distribute MR reviews evenly among maintainers
• Improvements in code review features and CI/tooling to support the maintainers and reduce work needed for reviews
• Coverage/monitoring measures to know when a part of the code base is adequately supported or needs help
• Improvements in onboarding maintainers at our new scale
• Have some fun

Tracking Progress

Progress will be tracked on the Working Group issue board using the following labels:

• ~“workflow::In dev”
  • The issue is currently in progress and actively being worked on
• ~“workflow::In review”
  • The issue is currently being reviewed by broader Engineering Team
• ~“workflow::blocked”
  • The issue is blocked by another issue. Please refer to the blocking issue.
• ~“workflow::production”
  • The issue has been completed and should be closed.

Exit Criteria (100% completed)

Exit criteria for this working group has been completed, however monthly follow up meetings are still active until February 2, 2023.

Maintainership Process

The maintainership process is described on this page.

Exit Criteria (100% completed)

#	Start Date	Target Completion Date	Completed Date	DRI	Criteria
1	2022-06-01	2022-07-22	2022-10-28	@nhxnguyen	Create an implementation plan to remedy gaps in Maintainership coverage
2	2022-04-26	2022-07-22	2022-07-18	@mwoolf	Develop metrics to provide more transparency into the health of the Maintainership program
3	2022-05-04	2022-08-05	2022-10-04	@robotmay_gitlab	Update expected behaviors and responsibilities for Engineers and Maintainers
4	2022-05-18	2022-08-05	2022-10-04	@oregand	Improve the Trainee Maintainer process to make the process more efficient
5	2022-06-01	2022-08-05	2022-11-16	@sabrams	Develop and implement a communication plan for Maintainership changes

Data and dashboards

• Reviewer/Maintainer availability and capacity - Shows the maintainer/reviewer availability rate over time and incoming/forecasted review requests
• Maintainers and Trainees
• Maintainership Demand

Roles and Responsibilities

Working Group Role	Person	Title
Executive Sponsor	Christopher Lefelhocz	VP of Development
Facilitator	Michelle Gill	Senior Engineering Manager, Manage
Functional Lead (Enablement)	Alex Ives	Engineering Manager, Database
Functional Lead (Fulfillment)	Jerome Ng	Senior Manager of Fulfillment
Functional Lead (Ops)	Sam Goldstein	Director of Ops
Functional Lead (Dev)	Max Woolf	Senior Backend Engineer, Govern:Compliance
Functional Lead (Sec, Data Science, Growth)	Thomas Woodham	Sr. Engineering Manager, Secure Analyzers
Functional Lead (Maintainer - Frontend)	Natalia Tepluhina	Staff Frontend Engineer
Functional Lead (Non-Maintainer - Backend)	Manoj M J	Senior Backend Engineer
Functional Lead (Trainee - Registry DB)	Steve Abrams	Intermediate Backend Engineer
Functional Lead (Maintainer - Workhorse, Shell)	Robert May	Senior Backend Engineer
Functional Lead (Maintainer - Frontend)	Ezekiel Kigbo	Senior Frontend Engineer
Functional Lead (Maintainer - Omnibus)	Balasankar C	Senior Backend Engineer
Functional Lead (Maintainer - CNG, Operator)	Mitchell Nielsen	Senior Backend Engineer
Member	Sean McGivern	Staff Backend
Member	Allen Cook	Senior Backend
Member	Terri Chu	Senior Backend
Member	Doug Stull	Staff Fullstack
Member	Pavel Shutsin	Senior Backend
Member	Sincheol Kim	Senior Backend
Member	Michał Zając	Senior Backend
Member	Douglas Barbosa Alexandre	Staff Backend
Member	Paul Gascou-Vaillancourt	Senior Frontend,
Member	Dennis Tang	Engineering Manager, Govern:Compliance
Member	Nick Nguyen	Senior Engineering Manager, Datastores
Member	Darva Satcher	Senior Engineering Manager, Create / Ecosystem Stage
Member	Jiaan Louw	Senior Frontend Engineer, Govern:Compliance
Member	Rémy Coutable	Staff Backend Engineer, Contributor Success

Communicating changes

Labels

We have two sets of labels to help facilitate communications:

Type of changes and their impact

Use these labels to identify the type of change being made:

• ~"Maintainership WG::process change" - This update changes an existing process or workflow
• ~"Maintainership WG::new process" - This update introduces a new process or workflow
• ~"Maintainership WG::responsibility change" - This update changes or introduces a responsibility
• ~"Maintainership WG::other change" - This is an update that may warrant an announcement but does not fit in the above categories

Communication status

Use these labels to identify if a change is ready to be communicated or if it has been communicated:

• ~"Maintainership WG Comms::ToDo" - This update is ready to be communicated
• ~"Maintainership WG Comms::Needs Support" - This update needs something additional to support it when it is announced. This could be things like handbook updates, an FAQ, or an AMA.
• ~"Maintainership WG Comms::Done" - This update has been communicated

Runbook

Levels of announcements

There are generally three types of announcements that could apply to any update:

1. Alert - Something certain individuals might want to be aware of.

Example: letting trainees and maintainers know that the program is meant to last one year, at which time it should be evaluated.

Alerts are the lowest priority type of announcement. If some people miss it, that is not a problem. Alerts can usually be announced one time.

1. Change - Something certain individuals need to be aware of.

Example: changing the number of approvals necessary to become a maintainer.

Changes usually require adoption, which is not something that happens after a single announcement. So it is important to not only communicate to the effected individuals, but also those who can endorse and promote the changes such as engineering managers or higher levels of management.

Some announcements may gain a wider audience if they come from someone in senior management. If the subject matter is high enough in priority, consider reaching out to your sub-department director for guidance or asking in an engineering staff meeting for help with the announcement.

1. Action - Something that requires certain individuals to take action within a given time period of the announcment.

Example: requesting survey feedback or communicating a behavior change that needs to be adopted within a certain time frame.

Depending on the priority and urgency of the action needed, additional reminders are appropriate. For surveys, reposting a few times within the time frame before the survey closes is appropriate.

Making an announcement

Consider the following questions when making an announcement:

• Are there any other areas of the docs or handbook that should be updated? Ensure there is no conflicting information that could cause confusion.

• Do you have links to the handbook or docs to accompany the announcement? Ensure more information is available for those who need it.

• Do you have a place where people can go with more questions or clarifications? Provide an issue/doc/slack channel/AMA if it is expected that people may want further details.

• Does this change disrupt an established process? If so, it may make sense to prompt managers to take action to raise awareness and adoption of the process.

• Is the change large enough that we may have a large number of questions? Consider opening an FAQ file or scheduling an AMA (@sabrams can also facilitate these items).

• Include links to the most relevant piece of information. Do not overcrowd the announcement with non-primary links.

• If the announcement is for awareness:

  • Communicate it to the most relevant slack channel and cross-post to other relevant channels
  • Add it to eng-week-in-review

• If the announcement is for action

  • Communicate as above and consider adding it to management staff meetings.

• If you are seeking feedback as a result, provide a link to where feedback can be given

Divisive changes

Sometimes changes are controversial or involve subjects where people might have deep opinions. It is important that when such changes occur, everyone has access to resources and information to help them understand:

• How they are affected
• Why the change was made
• Where they can give feedback

An FAQ or AMA can be helpful in supplying much of this information.

Ideally, we want people to embrace a change, but at the least, we need to start with adoption. To help guide embracement, the “why” behind the change has to be strongly defined, optimally with strong data backing it.

Conducting a survey

• Establish the goal of the survey
• Share in the most relevant slack channel and cross-post to other relevant channels
• Communicate the end date or due date for the survey
• Define a minimum number of responses to make the results representative/useful
• Add a question to distinguish between different subgroups if applicable (frontend/backend, reviewer/trainee/maintainer) for pivoting the results.

Communication channels

It is appropriate for almost any changes to be communicated in:

• #development
• #eng-week-in-review

Communicating in #whats-happening-at-gitlab is also a good idea for changes that effect large groups of people.

Here are a few different categorizations of changes that can help you decide which channels to consider communicating to.

By exit criteria

Exit Criteria	Relevant Channels
Create an implementation plan to remedy gaps in Maintainership coverage	Channels for the projects directly effected by the changes.
Develop metrics to provide more transparency into the health of the Maintainership program	#eng_managers Engineering staff meetings
Update expected behaviors and responsibilities for Engineers and Maintainers	#trainee_maintainers #backend_maintainers #frontend_maintainers #database_maintainers #eng_managers Engineering staff meetings
Improve the Trainee Maintainer process to make the process more efficient	#trainee_maintainers #backend_maintainers #frontend_maintainers #database_maintainers #eng_managers Engineering staff meetings

For gitlab-org/gitlab (GitLab Rails)

Topic	Relevant Channels
Backend	#backend #backend_maintainers
Frontend	#frontend #frontend_maintainers
Database	#database #database_maintainers
Trainee updates	#backend_maintainers #frontend_maintainers #trainee_maintainers
Responsibility/process updates	Any of the above channels and #eng_managers

Other projects

For changes concerning a specific project, try to notify the group that owns the project in addition to specific channels for that project. For example, workhorse changes should be communicated to #workhorse and #g_create_source_code as the owners of that project.

The product category page and the projects page may be helpful for determining which groups and stages own specific projects. If it is not apparent, another way to determine ownership include filtering the project members by direct membership and asking the owners or maintainers directly who owns the project.