Add Andrew Evans as a 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. -
The candidate is semi-frequently asked to merge changes or otherwise mistaken for a maintainer.
Contributions
Andrew has been at GitLab for >6mo, and has previously worked in senior and staff engineering roles at companies using Ruby-on-Rails as their primary application framework. At GitLab he has contributed to many parts of the stack including:
- The primary GitLab monolith - example MR
- GDK - adding SmartCard nginx configuration and doctor tests
- Omnibus - adding SmartCard ActiveDirectory settings
- Fixes through the security and security-fix-in-public processes: for example this change to GraphQL token handling
He has reviewed >60 MRs since becoming a trainee_maintainer
3mo ago. Some highlights include:
-
Use project or group organization for new project / group bots
- Pushed for additional spec coverage
-
Add renew secret REST API endpoint
- Community contribution
- Caught misnamed method
- Requested change of endpoint from
GET
toPOST
to better match industry standard and GitLab guidelines for REST APIs - Pushed for additional spec coverage
-
Prevent new user registration based on geo-ip data
- Suggested behavior improvement to better match the developer's intentions
-
Add new keep to remove duplicate indexes
- Pushed to use
asdf
Ruby version, rather than a constant, reducing potential future maintenance
- Pushed to use
-
Fix sign-out process to not delete cookies from "sibling" subdomains
- Reviewed a community contribution that might have some significant security concerns and coordinated to get AppSec review
-
Allow using AI query / subscription with ai_features token
- Requested more specs to ensure coverage of all conditions
- Pushed for clear error messages to help users identify problems
- Pushed for feature flag to de-risk any potential production issues
-
Pass group access token to policy code
- Made a number of suggested simplifications to improve code quality and reduce maintenance
- Caught an edge case where a feature flag was needed but missed
-
Limit unverified users to creation of 2 groups
- Pushed for integration tests due to heavy use of mocking in unit specs
- Caught missing coverage of feature-flag-disabled condition
-
Require confirmation before linking JWT identity
- Called out a potential security issue
- Security issue was later expanded into a full security report
-
Refactor onboarding status changes into service layer
- Assisted primary developer in determining tricky cause of extra db queries in specs
-
Use Project or Group organization for project/group bot namespace
- Carefully double-checked during feedback rounds to ensure that all code updates are pushed and visible on the MR branch
-
Use UntrustedRegexp for gollum pattern
- Spot-checked performance locally to ensure performance increase was reproducible
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 🤘 😎 🤘
Edited by Andrew Evans