Add Eugenia Grieff as backend maintainer
Manager Justification
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.
@egrieff has been at GitLab for over 4 years and has been a trainee maintainer for over 8 months (#13936 (closed)) with the help from @splattael as a mentor.
She has reviewed a total of 288 MRs of which 94 MRs were reviewed as a part of being a trainee maintainer, these span across 25 different groups. Notably, the last 23 MRs in a row were merged with minor to no suggestions required from the maintainers. Also during this training period, a total of 59 were merged as-is.
She focuses on ensuring that each MR aligns with the quality and consistency standards of the GitLab codebase. For instance:
- Simplify the code while still effectively solving the problem at hand [1, 2, 3, 4].
- Identify and address any broader concerns or potential oversights within the MR [1, 2, 3].
- Encourage the reuse of existing code where applicable [1].
- Highlight any areas of high complexity that may pose additional risks [1].
- Suggest improvements to enhance the overall quality [1, 2, 3] and readability of the code [1, 2, 3].
- Identify and recommend performance optimisations [1, 2, 3, 4].
- Ensure tests meet quality [1, 2], coverage [1, 2], and performance standards [1, 2].
She facilitates efficient communication by adhering [1] to the Conventional Comment format as outlined in GitLab’s guidelines, ensuring clear and concise feedback to convey her intentions. Additionally, she makes a conscious effort to understand the author’s perspective [1, 2] and ask questions whenever clarity is needed [1]. She differentiates between blocking and non-blocking suggestions [1, 2] and prioritises providing actionable comments over open-ended questions to aid the author in implementing changes effectively [2].
As an MR author, she takes a proactive approach to enhance the review process by providing detailed descriptions, including screenshots and step-by-step replication instructions [1, 2, 3]. She also conducts thorough self-reviews to minimise review cycles, resulting in a higher likelihood of her MRs being approved without requiring significant modifications during the review and maintenance stages [1, 2, 3].
Highlighted reviews
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 please approve or give a 👍 on the MR
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_maintainersSlack 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 -
Announce it everywhere -
Keep reviewing, start merging 🤘 😎 🤘