Make Michael Becker (@wandering_person) a backend maintainer
Summary
It's hard to specify hard requirements for becoming a maintainer, which is why the documentation consists of flexible guidelines. Reviewers are encouraged to think of their eligibility for maintainership in the terms of "I could be ready at any time to be a maintainer as long as my work as an author and reviewer is consistent with other maintainers".
-
The MRs reviewed by the candidate consistently make it through maintainer review without significant additionally required changes. -
The MRs authored by the candidate consistently make it through reviewer and maintainer review without significant required changes.
The evidence shows that my reviews are on-par with other maintainers.
MRs Reviews (merged) | MRs Reviews (open) |
---|---|
184 | 2 |
label | merged | open |
---|---|---|
~"Community contribution" | 14 | 1 |
Justification
The following MRs demonstrate a commitment to quality. I also strive to explain the why in my suggestion, and back it up with some evidence.
- gitlab-org/gitlab!142565 (comment 1739631104)
- gitlab-org/gitlab!142824 (comment 1744486960)
- gitlab-org/gitlab!143045 (comment 1748691792)
I try to state all of my assumptions, especially if reviewing in an unfamiliar domain. This is to both help subsequent reviewers, and to afford the author/other reviewers an opportunity to correct any inaccuracies in a transparent way:
The following MRs highlight collaboration as they involve an async back-and-forth to either work through a problem, or even jump on a video call to assist a colleague
- gitlab-org/gitlab!141205 (comment 1719492355)
- gitlab-org/gitlab!139711 (comment 1693976400)
- gitlab-org/gitlab!142989 (comment 1747334184)
- gitlab-org/gitlab!140648 (comment 1708611145)
When I think an MR could be broken down into smaller MRs, I try to re-iterate that value of small MRs, while at the same time respecting my colleagues expertise. From an outside perspective, it may look like an MR could be broken up, but perhaps there is some context I am not privy to that necessitates a larger MR.
I try to strike this balance by 1) re-iterating the value in 2) a non-blocking comment that 3) contains possible examples of how to divide up similar MRs in the future
Before Merging (Manager Tasks)
-
Close any relevant trainee maintainer issues with a comment indicating that this merge request is being created, as (they are no longer required to become a maintainer). -
Mention the maintainers from the given specialty with the template below. -
Leave this merge request open for 1 week, to give the maintainers time to provide feedback. -
Ensure we have at least 2 approvals from existing maintainers.
Template call to action
SPECIALITY Maintainers, please review this proposal to make TRAINEE maintainer of PROJECT.
* If you have blocking feedback adhering [to the documentation](https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer) please share it with me via Slack.
* If you are in agreement, and can vouch for this proposal, please approve.
After 1 week, if there is no blocking feedback and at least 2 approvals, I will merge this MR.
Once This MR is Merged
-
Join the #backend_maintainers
Slack channel -
Ask the maintainers in your group to invite you to any maintainer-specific meeting if one exists. -
Let a maintainer add you to @gitlab-org/maintainers/rails-backend
withOwner
access level. -
Announce it everywhere -
Familiarize yourself with documentation for Merging a merge request -
Keep reviewing, start merging 🤘 😎 🤘
related to: #34701 (closed)