Skip to content

Make @pgascouvaillancourt a GitLab frontend maintainer

Paul Gascou-Vaillancourt requested to merge pgv-gitlab-fe-maintainer into master

I believe the time has come for me to (try to) become a GitLab maintainer.

A few trivias as of writing this:

How I handle reviews

Here are my priorities when I receive a review request:

  • First and foremost, I try to submit reviews in a timely fashion. At GitLab, helping others is a priority. I generally consider unblocking fellow team members more important than my own work.
  • I put my personal preferences aside. We all have learned coding in our very own ways and matters of taste should not interfere in reviews. Most of the time, I won't suggest a change when both versions of the code produce the same result unless the readability and or performances are drastically increased.
  • I smoke-test almost all the MRs I review. If the changes are minor-enough, I will consider skipping the testing step. When I feel smoke-testing is required, but setting up my GDK would take an unreasonable amount of time, I will consider handing the MR over to a domain expert.
  • I default to non-blocking. Unless something really feels wrong about an MR, I will never block it. As a GitLab reviewer, I've gotten used to submitting my reviews and approving the MR early without assigning a maintainer yet. This leaves it up to the author to address the comments or not, and moving on to the next stage whenever they feel ready.
  • I like to make my suggestions as easy to apply as possible, either by using GitLab's built-in suggestion feature, or providing Git patches for more complex changes.

Any good examples?

A previous version of this MR description contained an unordered and poorly formatted list of recent MR reviews of mine. Providing examples used to be the standard prior to the maintainership working group disbanding. I liked that and wanted to do it here, even though it's not a requirement anymore. But this feels unreasonable at the moment due to current priorities (%16.0 is around the corner basically). I've given up on going through my reviews to find tangible justifications for this application.

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 it is justified".

  • 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.

Paul has been a reviewer of GitLab for four years and a maintainer of GitLab UI for three of those. In that time, he's reviewed over 1,500 MRs. Paul is a proven reviewer and maintainer and could not be more ready for this next step.

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 and ask them to provide feedback to the manager directly.
  • 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.

Once This MR is Merged

  1. Create an access request for maintainer access to gitlab-org/<project>.
  2. Join the [at]frontend-maintainers slack group
  3. Ask the maintainers in your group to invite you to any maintainer-specific meeting if one exists.
  4. Let a maintainer add you to gitlab-org/maintainers/frontend
  5. Announce it everywhere
  6. Keep reviewing, start merging 🤘 😎 🤘
Edited by Paul Gascou-Vaillancourt

Merge request reports