Add Luke Duncalfe (@.luke) as backend maintainer of GitLab
Trainee maintainer issue: #6281 (closed)
Overview
I have been a backend engineer at GitLab for 18 months, and have been a trainee maintainer for 9 months.
My main reasons for wanting to become a maintainer are:
- I'd like to "give back" to other engineers (and help the backend maintainers with their review load).
- I care about the stewardship of the GitLab codebase.
- I enjoy the process of code review and interacting (sometimes meeting) with engineers over their code.
- Reviewing is a very effective way to increase my knowledge of GitLab and powers as an engineer.
Some stats: I have authored 230+ merge requests, and, during my traintainership, have reviewed ~120 merge requests. My trainee issue lists only 65 merge requests as I have skipped adding merge requests that were reasonably simple or didn't offer enough to discuss with a maintainer about.
The recent few months of feedback from maintainers have been positive, and I've regularly seen merge requests I review be merged with few, if any, changes.
Examples of reviews
- gitlab-org/gitlab!35455 (merged)
- gitlab-org/gitlab!34673 (merged)
- gitlab-org/gitlab!32446 (merged)
- gitlab-org/gitlab!34141 (closed) and gitlab-org/gitlab!36331 (merged)
- gitlab-org/gitlab!33041 (merged)
- gitlab-org/gitlab!30140 (merged)
- gitlab-org/gitlab!31169 (merged)
- gitlab-org/gitlab!32817 (merged)
- gitlab-org/gitlab!27428 (merged)
- gitlab-org/gitlab!28273 (merged)
- gitlab-org/gitlab!31867 (merged)
- gitlab-org/gitlab!33492 (merged)
- gitlab-org/gitlab!32329 (merged)
Things to improve
- There have been a couple of times that I have regretted not persisting more with the review process when there were still necessary changes to be made after a bit of back-and-forth with the author. Although I've tried to "review as a maintainer" during the traineeship, it's possible that in these situations I've relied on there being a second pair of eyes to follow, and my goal as a maintainer would be to continue to persist during the review when these situations arise. (The caveat being; to also judge accurately when you may be wrong about something, or when to leave things for a follow-up).
- Pay special attention to the performance of queries #6281 (comment 434032622) and, in general, always consider the performance implications of changes.
- To maintain the concentration needed to give a thorough review, and notice when I'm tired and need a break
☕ .
@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
-