Make Nathan Friend (@nfriend) a frontend maintainer

Summary

This MR is my proposal to become a frontend maintainer for gitlab-org/gitlab and gitlab-org/gitlab-ui.

I believe I meet the guidelines laid out in the handbook:

1. In general, the further along in their career someone is, the more we expect them to be capable of becoming a maintainer.

I've been writing and reviewing code at GitLab since December of 2018 (1 year, 3 months).

2. Maintainers should have an advanced understanding of the GitLab codebase.

I've written and reviewed code from a variety of different "eras", whether it involved static Haml templates, vanilla JavaScript/jQuery scripts, early Vue components and Karma tests, or modern Vue apps written with Vuex and Jest.

Trainee maintainer

I've been a trainee maintainer for about 4 months. Here is my trainee issue: #5730 (closed).

Merge requests I've reviewed

Here is a list of merge requests I've reviewed, along with a quick description/highlight:

• EKS Cluster form static fields and security groups dropdown +512 -110
  • A deep dive into a third-party library revealed a nice way to clean up the code using Promises. (See gitlab-org/gitlab!17762 (comment 225674264)). No further comments from Mike.
• Add vuex store for package list app +334 -0
  • A large conversion of a view from Haml to Vue spanning multiple MRs. A compliment and no further comments from Mike.
• Remove second primary button from feature flags empty state 1st contribution +45 -32
  • I walked a first-time (code) contributor through her first frontend MR. One small comment from Paul.
• Resolve "Add UI event tracking for container registry" +258 -104
  • Some questions, but no resulting changes, from Martin. Also a compliment.
• Project Releases pagination implementation ~"Community Contribution" +158 -34
  • I recommended a number of small improvements to a community MR. No further comments from Clement.
• Refactor Geo Node License Flash +76 -41
  • I expressed concern with the way a Haml alert message was being implemented and recommended we brainstorm a way to use a GlAlert instead. A new issue and merge request was created which I coached through several review cycles. As part of my review, I wrote my own MR to help communicate my suggestions. One small comment from Paul.

Merge requests I've authored:

Lately I've been focusing on breaking issues down into lots of small MRs hidden behind feature flags. Here are a few complete examples of features I recently implemented:

Create a dedicated page for viewing and linking each Release (#32827)

• Create backend route for dedicated Release page backend +63 -6
• Make titles on the Releases page link to dedicated Release page +70 -5
• Add "self" link to Release API response backend +23 -0
• Restructure releases/** JavaScript in preparation for new show page +123 -74
• Reference all Release data using camelCase +114 -96
• Update redirect behavior of Edit Release page +297 -165
• Create dedicated release page for each Release +443 -164
• Enable the dedicated Release page +8 - 3

Make it possible to edit a release using the UI (#26016)

• Add "Edit Release" page +795 -0
• Rearrange the Vue release components +12 -16
• Follow up to !18131: Move test files +4 -4
• Add "edit" button to release blocks on Releases page +457 -58
• Update release blocks to look for correct property name in API response +10 -5
• Update "Tag name" help text on Edit Release page +74 -20
• Add documentation for new "edit release" feature/page +21 -0
• Add Release "edit" page feature spec +72 -0
• Update "Edit release" page feature flag to be enabled by default +3 -3

Allow milestone(s) to be associated with a release (#29020)

• Add release links to tags on Tags page +23 -4
• Add Release Links to Milestone List Page +69 -8
• Add milestones to release blocks +345 -168
• Update release blocks to support multiple milestones +78 -129
• Add links to associated release(s) to the milestone detail page sidebar +133 -3
• Document Milestone <> Release feature +37 -14

I try to regularly step outside of ~"group::release management" and make "quality of life" improvements that improve the efficiency of the entire organization:

• Add pngquant:compress and pngquant:lint rake tasks backend documentation +104 -0
• Suppress AJAX errors caused by browser navigation +84 -0
• Make pipeline failure Slack notifications prettier and more informative backend +671 -104
  • Follow-up PRs to fix upstream issues with Mattermost:
    • GH-11994: Add support for footer and footer_icon in attachments +277 −1 (desktop/web app)
    • GH-11994: Add support for footer and footer_icon in attachments +260 −0 (mobile app)
• feat(b-tooltip, b-popover): allow global delay customization +18 −8 (against the bootstrap-vue repo)
• Frontend RFC: New: Populate Vuex store's initial state when creating store

Process

From the handbook:

• Create a MR to add the maintainership to their team page entry.
• Explain in the MR body why they are ready to take on that responsibility.
• Use specific examples of recent "maintainer-level" reviews that they have performed.
• Assign the MR to their manager and mention the existing maintainers of the relevant product and area.