Following the introduction of the *Member* role, restructure the *Committer* role to align more closely with the structure of the *Member* role. While doing this, also make a couple of tweaks to the role:
- Rename the role from *Commit Access* / *Committer* to *Code Merger*
- Slight change in phrasing for the requirements specifying *small to medium-sized, non-trivial, high-quality* and allowing *little guidance* instead of *accepted without modifications*
- *Code Merger* can be granted on a per-repository basis instead of the current *Commit Access* role, which is phrased as giving commit access to all repos at the same time.

There has been a lot of discussion around the naming of this role. Names that we have rejected are:

- *Approver*: Same reason as *Reviewer*.
- *Collaborator*: Naturally feels like it is a level below *Member*. Also, GitHub shows a *Collaborator* badge if you are a collaborator of a repo in an organization but not a member of the organization itself, which isn’t the case here.
- *Apprentice*: Naturally feels like a level below *Member*.
- *Associate*: A very vague term that does not carry any meaning of the privileges or responsibilities at the level.
- *Colleague*: Implies a joint employer between colleagues and thus might imply that this role is only accessible to Apple employees.
- *Member with Merge Access* (or similar): All the other roles are single terms and *with Merge Access* falls out of that naming scheme.
- *Senior* Member: This implies that the previous role would be a *Junior Member* and people prefer not to be junior.
- *Committer*: When a *Contributor* gets their first PR merged, they have a commit in the repo. It feels surprising if the *Committer* level is two levels higher. Other projects use this term (including the current [Community Structure](https://www.swift.org/community/#community-structure) page on swift.org) but it feels like this term originates from workflow using SVN or before PRs in Git, where changes were directly committed to main.
- *Merger*: Merger usually refers to the result of a merge (eg. the merger of two companies), not the person performing the merge. Also, at this level, a contributor can still only merge after approval from *Code Owners*, so the term might be misleading.
- *Merge Access*: All the other roles fit into the it naming scheme *I am a ... in the Swift project* but *Merge Access* does not.
- *Member*: This would meant hat we need to find new names for the current *Member* role, which would no longer match the badge that GitHub shows next to your name.