Add Ethan Urie as backend maintainer

Trainee maintainer issue: #5962 (closed) (FWIW, I didn't record some issues where I approved as-is and it was merged as-is too)

Overview

I've been with GitLab in the Security Engineering team for over 2.5 years, doing code reviews as a trainee for almost that long.

I've always been a slow and deliberate reviewer, trying to be as thorough as I can be, with the code quality and not breaking anything as my primary concerns.

That said, I believe I have always presented my suggestions and questions in the light of collaboration and working together to make our code better.

I've been regularly impressed at the high quality of our code, in general - I rarely have comments or suggestions about design or performance issues.

As for authoring MRs, I've authored 40+ that have been merged, in the Gitlab project as well as others. I recognize that that's fewer than many other trainees, and it's mostly due to not working in the GitLab codebase every day since I'm on Security Automation. However, I feel my contributions have been of high quality when I have made them.

As part of the Security Automation team, I had a large part in implementing the Spamcheck anti-spam engine and integrating it into GitLab.

Examples of reviews

• Sliding list partitioning strategy gitlab-org/gitlab!73406 (merged)
• Add and use gl_badge_tag helper in runner settings: gitlab-org/gitlab!73858 (merged)
• https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/1863
• Adding area_of_focus to members/invites: gitlab-org/gitlab!64956 (merged)
• Limit reindexing concurrency: gitlab-org/gitlab!44036 (merged)
• Add Rubocop rules for counters on large tables: gitlab-org/gitlab!36314 (merged)
• Allow to unassigned Issues and MRs when member leaves team: gitlab-org/gitlab!34388 (merged)
• Statistics about amount of clusters configured: gitlab-org/gitlab!32761 (merged)
• Iterate over trailing space regex replacements: https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/1863

Things to improve

1. I need to improve my eye for potential query performance issues - I'm constantly worried that I'm going to miss a change that drastically impacts database performance, and so I'm paying close attention to opportunities to improve there.
2. I need to be quicker to ask for second opinions from maintainers when I'm unsure of something. I often like to work through problems myself to get a more thorough understanding of the code, but I can sometimes let it go on too long.
3. I am not the fastest reviewer, erring on the side of caution and trying to be thorough (and watching for potential performance issues). I realize that this can be frustrating for devs with large MRs that need to get in to a release quickly. I'm working on this.

@gitlab-org/maintainers/rails-backend please chime in below with your thoughts, and approve this MR if you agree.

Developer checklist

• Before this MR is merged
  • Mention @gitlab-org/maintainers/rails-backend, if not done (this issue template should do this automatically)
  • Assign this issue to your manager
• After this MR is merged
  • Request a maintainer from the #backend_maintainers Slack channel to add you as an Owner to gitlab-org/maintainers/rails-backend
  • Consider adding 'backend maintainer' to your Slack notification keywords

Manager checklist

• Before this MR is merged
  • The MR has been open for 5 working days
  • More than half of the existing maintainers approve the MR (see the maintainer list)
  • There are no blocking concerns raised (if there are, please follow https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer)
• After this MR is merged
  • Announce the good news in the relevant channels listed in https://about.gitlab.com/handbook/engineering/#keeping-yourself-informed