| Property | Value |
|---|---|
| Date Created | 2022-04-19 |
| Target End Date | 2022-07-29 |
| Slack | #wg_maintainership |
| Google Doc | Working Group Agenda |
| Task Board | Issue board |
| Epic | Link |
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:
Progress will be tracked on the Working Group issue board using the following labels:
| # | Start Date | Target Completion Date | Completed Date | DRI | Criteria |
|---|---|---|---|---|---|
| 1 | 2022-06-01 | 2022-07-22 | TBD | @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 | TBD | @robotmay_gitlab | Update expected behaviors and responsibilities for Engineers and Maintainers |
| 4 | 2022-05-18 | 2022-08-05 | TBD | @oregand | Improve the Trainee Maintainer process to make the process more efficient |
| 5 | 2022-06-01 | 2022-08-05 | TBD | @sabrams | Develop and implement a communication plan for Maintainership changes |
| 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, ModelOps, 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 | Kyle Wiebers | Engineering Manager, Engineering Productivity |
| 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 |
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 categoriesCommunication 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 communicatedThere are generally three types of announcements that could apply to any update:
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.
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.
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.
Consider the following questions when making an announcement:
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).
Sometimes changes are controvertial or involve subjects where people might have deep opinions. It is important that when such changes occur, everyone has access to resouces and information to help them understand:
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.
It is appropriate for almost any changes to be communicated in:
#development#eng-week-in-reviewCommunicating 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.
| 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 | <ul><li>#eng_managers</li><li>Engineering staff meetings</li></ul> |
| Update expected behaviors and responsibilities for Engineers and Maintainers | <ul><li>#trainee_maintainers</li><li>#backend_maintainers</li><li>#frontend_maintainers</li><li>#database_maintainers</li><li>#eng_managers</li><li>Engineering staff meetings</li></ul> |
| Improve the Trainee Maintainer process to make the process more efficient | <ul><li>#trainee_maintainers</li><li>#backend_maintainers</li><li>#frontend_maintainers</li><li>#database_maintainers</li><li>#eng_managers</li><li>Engineering staff meetings</li></ul> |
gitlab-org/gitlab (GitLab Rails)| Topic | Relevant Channels |
|---|---|
| Backend | <ul><li>#backend</li><li>#backend_maintainers</li></ul> |
| Frontend | <ul><li>#frontend</li><li>#frontend_maintainers</li></ul> |
| Database | <ul><li>#database</li><li>#database_maintainers</li></ul> |
| Trainee updates | <ul><li>#backend_maintainers</li><li>#frontend_maintainers</li><li>#trainee_maintainers</li></ul> |
| Responsibility/process updates | Any of the above channels and #eng_managers |
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.