Trainee FE maintainer (Gitlab) - Sheldon Led
I couldn't find the official template for this issue, so I've inspired on #13386, #14556 (closed), #7005 (closed), and #13688 (closed)
Summary
- Maintainer of
CustomersDot
- Working on GitLab project for 3 years (first MR - which coincidentally was a take over from Community contribution gitlab-org/gitlab!65410 (comment 821173831))
- Reviewed and approved 335+ MRs, some MRs with different aspects such as:
- 20 were Community contribution
- 21 with no frontend code
- Provided backend and ~test feedback, sometimes with no additional feedback from domain experts
- Coached other engineers on writing better tests and avoid
rubocop:disable
gitlab-org/gitlab!119942 (comment 1392631483) - Since the Trainee Maintainer Issue was opened (2023-07-11) here's the TL;DR of the reviews:
- Total: 93
- No feedback: 40 (43.01%)
- Merged as-is: 69 (74.19%)
- No substantial additions: 5 (5.38%)
- Maintainer's comments weren't crucial or could've been addressed in a follow up (in my opinion): 11 (11.83%)
- Here are a few reviews that stood out as non-trivial:
Basic setup
-
Read the code review page in the handbook and the code review guidelines. -
Understand how to become a maintainer -
Create a merge request updating your team member entry adding yourself as a trainee maintainer -
Ask your manager to set up a check in on this issue every six weeks or so -
Join the #trainee_maintainers
Slack channel
Working towards becoming a maintainer
These are only guidelines. Remember that there is no specific timeline on this.
As part of your journey towards becoming a maintainer, you may find it useful to:
-
Act as a coach in a big deliverable that requires following the planning step as part of the trainee program. -
Shadow a maintainer while they review an MR. This will allow you to get insight into the thought processes involved. -
Have a maintainer shadow you while you review an MR as if you were a maintainer . Ideally, this would be with a different maintainer to the above, so you can get different insights.
It is up to you to ensure that you are getting enough MRs to review, and of varied types. All engineers are reviewers, so you should already be receiving regular reviews from Reviewer Roulette. You could also seek out more reviews from your team, or #frontend Slack channels.
Your reviews should aim to cover maintainer responsibilities as well as reviewer responsibilities. Your approval means you think it is ready to merge.
After each MR is merged or closed, add a discussion to this issue using this template:
### (Merge request title): (Merge request URL)
During review:
- (List anything of note, or a quick summary. "I suggested/identified/noted...")
Post-review (opportunities to learn):
- (List anything of note, or a quick summary. "I missed..." or "Merged as-is")
(Maintainer who reviewed this merge request) Please add feedback, and compare
this review to the average maintainer review.
The purpose of comparing your review to the maintainer's review is to engage in active learning and expand your list of items to consider. Remember, different maintainers are going to identify different issues in the same code. As long as you are not missing large errors or bugs, don't feel like you are doing a bad job if you and a maintainer make different suggestions.
Note:
- Do not include reviews of security MRs because review feedback might reveal security issue details.
- Every trainee maintainer is encouraged to list all reviews, but may opt to not ask for maintainer feedback in trivial merge requests. This is also in sync with being respectful of other's time
Tip: There are tools available to assist with this task.
Code Review Pairing
Much like pair programming, pairing on code review is a great way to knowledge share and collaborate on merge request. This is a great activity for trainee maintainers to participate with maintainers for learning their process of code review.
A private code review session (unrecorded) involves one primary reviewer, and a shadow. If more than one shadow wishes to observe a private session, please consider obtaining consent from the merge request author.
A public code review session involves a primary reviewer and one or more shadows in a recorded session that is released publicly, for example to GitLab Unfiltered.
- If the merge request author is a GitLab team member, please consider obtaining consent from them.
- If the merge request author is a community contributor, you must obtain consent from them.
- Do not release reviews of security merge requests publicly.
When you're ready to make it official
When reviews have accumulated, and recent reviews consistently fulfill maintainer responsibilities, any maintainer can take the next step. The trainee should also feel free to discuss their progress with their manager or any maintainer at any time.
-
Create a merge request updating your team member entry using the template proposing yourself as a maintainer. -
Keep reviewing, start merging 🤘