Add Mireya Andres as GitLab 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.

Mireya has been a frontend engineer for ~3 years and has worked closely with grouppipeline authoring and now grouppipeline security. In that time, she has...

• Reviewed 354 merge requests
• Authored 143 merge requests
• Recently been training to become a maintainer under @pslaughter's mentorship.
• Gone through the onboarding process and has become a maintainer for gitlab-web-ide.

Values demonstrated during reviews

• Locally tests changes: 1, 2, 3
• Not afraid to ask questions: 1, 2
• Refers to documentation: 1, 2
• Gives praise and encouragement: 1, 2, 3
• Involves other domain experts to review changes: 1, 2, 3
• Utilizes patches and code suggestions to help keep MRs moving: 1, 2
• (Discussion) Architectural Decisions: 1, 2 (thread) (same MR)
• Prioritizes MR quality:
  • User experience. Does the change create a useful, robust, and loveable user experience? 1 (thread), 2, 3, 4
  • Reliability. Is the code reliable? Is the code returning the same output each time or are we introducing a lot of unpredictable side effects? 1, 2 (thread)
  • Dependencies and fragility. Does the code in this merge request introduce fragility, or external or internal dependencies into the codebase? Keep in mind that every time a dependency is leaned on it becomes something else to support. 1, 2
  • Maintainability. Will we be able to easily make changes to the relevant code (for example, bug fixes and requirements changes)? Are we adding more code than necessary? 1, 2
  • Readability. Could a brand new contributor jump into the relevant code and understand what's going on? 1, 2, 3, 4
  • Testing. Tests should almost always be provided for any change. Do the tests cover the features use cases and the component contracts? Will the tests ensure the user experience stays loveable with future changes? 1, 2
  • Consistency. Is the changeset consistent with the pre-existing code at both a higher level and a lower level? 1, 2

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 with Owner access level.
5. Announce it everywhere
6. Keep reviewing, start merging 🤘 😎 🤘