Propose Aleksei Lipniagov as a BE Maintainer
Trainee maintainer issue: #7702 (closed)
Overview
I contribute to GitLab for 2+ years working in the Memory team, and I've been in review training for more than a year, reviewing on MRs and reflecting on the Maintainer comments that were left on top of my reviews. I reviewed 130+ MRs during that period. I worked on the important parts of the app with my team such as Load Balancing/Image Scaling/Ruby 3 updates and I was exposed to how the risky changes are being approved/reviewed/rolled out by other maintainers.
Obviously, there were some MRs where the Maintainer contributed important suggestions on top of my reviews, but I consider this to be normal and part of the growth process.
I feel confident enough at that point to judge about the code and to be able to ping the domain expert/find another opinion if I am not 100% sure about the changes being made. I think that the best next step at that point for me would be to actually become a maintainer and grow in that role. I will pay max attention to the initial approvals and beyond, and having 2 Maintainers in our team would allow me to have an additional opinion quickly if needed.
Examples of reviews
- gitlab-org/gitlab!52727 (merged)
- gitlab-org/gitlab!58171 (merged)
- gitlab-org/gitlab!61501 (merged)
- gitlab-org/gitlab!61745 (merged)
Things to improve
There are always things to improve:
- Learn more about different domains of the app (e.g. I am not so familiar with our GraphQL/API code)
- Keep in mind the product value of the change is made
- Evaluate possible risks, especially when it comes to fragile parts of the app, such as initializers/dependencies
- Test manually more when needed and think of possible edge cases
- Keep in mind .com/self-managed dichotomy and the fact that we can't instantly deliver fixes to self-managed, be aware of the release schedule and cycle
- Check the "#master-broken" and "#production" channel regularly
@gitlab-org/maintainers/rails-backend please chime in below with your thoughts, and approve this MR if you agree.
Developer checklist
-
Before this MR is merged -
Mention @gitlab-org/maintainers/rails-backend
, if not done (this issue template should do this automatically) -
Assign this issue to your manager
-
-
After this MR is merged -
Request a maintainer from the #backend_maintainers
Slack channel to add you as an Owner togitlab-org/maintainers/rails-backend
-
Consider adding 'backend maintainer' to your Slack notification keywords
-
Manager checklist
-
Before this MR is merged -
The MR has been open for 5 working days -
More than half of the existing maintainers approve the MR -
There are no blocking concerns raised (if there are, please follow https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer)
-
-
After this MR is merged -
Announce the good news in the relevant channels listed in https://about.gitlab.com/handbook/engineering/#keeping-yourself-informed
-