Propose James Nutt as backend maintainer

Mentor Justification (@mwoolf)

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 my work as an author and reviewer is consistent with other maintainers".

• 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.

James has performed approximately 110 reviews as a trainee maintainer. Having been James' mentor for a number of months now (and a colleague in a previous, very similar, role), I'm very satisfied that he has the skills and ability to perform as an effective backend maintainer.

Stand-out reviewed MRs

• Remove the need for SaaS to configure Product A... (gitlab-org/gitlab!147833 - merged) • Max Woolf • 16.11
  • Despite being out of James' domain expertise, he was able to reason about the wider implications and this sparked a discussion to be resolved by the proudct team.
• Trigger note-webhook on comment edit (gitlab-org/gitlab!127169 - merged) • Lucas Zampieri • 16.11
  • James focussed on the tests on this Community contribution and helped lead the contributor to merge successfully.
• Add throttle definition for unauthenticated HTT... (gitlab-org/gitlab!147112 - merged) • Gerardo Navarro • 17.0
  • A complex, large Community contribution which started a conversation about whether it’s better to introduce a perfect change, or a change which is consistent with its neighbours. James rightly noted that the community contribution required AppSec review.
• Adds support for aria-label in `icons_helper#sp... (gitlab-org/gitlab!147028 - merged) • Rahul Chanila • 16.11
  • James focussed on accessibility

Potential areas of improvement

• Remembering secondary stuff
  • Is the milestone set?
  • Have we tagged in the appropriate database/technical writing review?
  • Are relevant docs updated? E.g. adding history trailer to appropriate doc section when a feature flag is removed.
• RSpec.
  • I’m reading Effective RSpec 3, which is excellent, but I’m still playing catch-up after being a minitest chap for so long. I generally know a good spec from a bad one, but I'm still picking up RSpec idioms and the cool stuff you can do with it.
• Internalising changes
  • It was announced in Engineering FYI or somewhere like that, but I managed to forget about the directive to introduce new application settings as JSONB fields between the announcement and the next MR I reviewed that happened to introduce one. Whoops.

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.
• 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. Join the #backend_maintainers Slack channel
2. Ask the maintainers in your group to invite you to any maintainer-specific meeting if one exists.
3. Let a maintainer add you to @gitlab-org/maintainers/rails-backend with Owner access level.
4. Announce it everywhere
5. Familiarize yourself with documentation for Merging a merge request
6. Keep reviewing, start merging 🤘 😎 🤘