Eduardo Sanz as frontend maintainer

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.

Eduardo has been part of the ~"group::authentication and authorization" team just under a year but as the primary ~Frontend engineer on the team he has contributed to numerous key features such as FedRamp compliance by removing the use of redis between backend and ~Frontend, 2FA management for enterprise users and owning UI for WebAuthn support.

Spanning over 120 MRs contributions, he is an active participant in the Pajama migration and thorough/kind in his reviews, mentoring the authors when the changes need to be broken down or iterated over along with blocking and non-blocking suggestions.

Demonstrates GitLab values in code review

• Direct authors to the documentation: example, and example
• Don't be afraid of asking questions: example, example
• Give encouragement: example, example
• Guide community and JiHu contributors: example and example
• Encourage to breakdown large MR into smaller MRs: example, result
• Thorough and detailed reviewer without being a blocker: example, example, example, example, example
• Attention to the UI: example, example
• Involve UX and technical writers to review changes: example, example
• Proactive (show-how or do-it-yourself-approach): example, example
• Give examples: example, example
• Explore alternative ideas: example
• Locally testing the changes: example, example
• Do not raise artificial suggestions: example
• Humble (ready to learn): example, example

Demonstrates expertise in key areas of GitLab

• Mobile first approach: example
• Vue: example
• Accessibility/usability: example, example
• Jest and test pyramid: example
• eslint: example

Before Merging (Manager Tasks)

• 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 🤘 😎 🤘