Make thomasrandolph maintainer of gitlab project

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.

@andr3: Thomas has been a Senior Frontend Engineer at Gitlab for six years. In that time he has:

• Reviewed & approved more than 700 merge requests
• Authored more than 440 merge requests, 360+ were merged.
• Gone out of his way to collect feedback from his reviews to help him improve the quality of his reviews (with a tool he developed) showing his dedication to align with maintainer expectations.

His track record below shows the scope of his impact through an avid reviewer. Maintainer level wasn't initially pursued and only more recently pushed more consciously for this goal.

I believe Thomas is ready for maintainership now due to examples below and the feedback I've received from his reviews by peers as well as his async communication.

Values demonstrated during reviews:

• Locally tests changes 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
• Acknowledges own blind spots 1, 2, 3, 4
• Refers to documentation 1, 2, 3, 4
• Gives praise and encouragement: 1, 2, 3, 4, 5, 6
• Involves other domain experts to review changes: 1, 2, 3, 4, 5
• Utilizes patches and code suggestions to help keep MRs moving: 1, 2, 3, 4, 5, 6, 7
• Prioritizes MR quality:
  • Reliability. 1, 2, 3, 4
  • Dependencies and fragility. 1, 2, 3
  • Maintainability. 1, 2, 3, 4, 5, 6, 7
  • Consistency. 1, 2, 3, 4, 5, 6, 7

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 and ask them to provide feedback to the manager directly. Emphasize that any negative feedback should be communicated privately to the manager/mentor, not in the merge request, as outlined in our maintainership feedback documentation.
• Leave this merge request open for 1 week, to give the maintainers time to provide feedback.
• Check this box to confirm that you approve the access provision.
• Ensure we have at least 2 approvals from existing maintainers.

Template call to action

`@gitlab-org/maintainers/frontend` Maintainers, please review this proposal to make TRAINEE maintainer of PROJECT.

* If you have blocking feedback adhering [to the documentation](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#request-maintainership-feedback) please share it with me.
* 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

1. Join the [at]frontend-maintainers slack group
2. Let a maintainer add you to <project>/maintainers/frontend with Owner access level.
3. Announce it everywhere
4. Familiarize yourself with documentation for Merging a merge request
5. Keep reviewing, start merging 🤘 😎 🤘

MR description notes: Notable/referenced reviews from the last 2-3 years

01 02 03 04 05 06 07 08 09 10
11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60