Maintainers

A repository's maintainer set isn't a list on a server — it's a set of announcements that reference each other. That has one consequence worth understanding before you invite anyone.

Roles

Role	Can publish git state	Can merge	Can manage issues & PRs	Can change the roster
Co-maintainer	yes	yes	yes	yes
Lead maintainer	yes	yes	yes	yes, and coordinates the roster
Moderator	no	no	yes	no

A moderator can publish issue, proposal and patch status events — including recording a merge that already happened — but cannot publish git state or perform a merge.

A lead has co-maintainer authority plus responsibility for coordinating the roster. When a lead is present, clients expect co-maintainer coordinates to forward to them, and ngit restricts normal roster management to that lead-shaped workflow.

Membership is reciprocal

WARNING

Listing someone is an invitation, not an appointment.

Until the person you named publishes their own announcement acknowledging the role, they are "invited", and their events are not authoritative for this repository.

This is deliberate. If a one-sided listing were enough, anyone could name a well-known developer as maintainer of a repository they've never seen, and borrow their reputation. Requiring the invitee to publish makes that impossible.

The normal flow:

# Alice invites Bob. Alice becomes lead automatically.
ngit repo edit --add-maintainer <bob-npub>

# Bob accepts, confirming Alice as lead.
ngit repo accept

# Bob can host the git data too, while accepting.
ngit repo accept --grasp-server grasp.example.com

Changing the roster

One relationship at a time:

ngit repo edit --add-maintainer <npub>
ngit repo edit --remove-maintainer <npub>
ngit repo edit --lead-maintainer <npub>
ngit repo edit --acknowledge-maintainer-change <npub>

The first add by a sole maintainer makes that publisher the lead. For a deliberately leadless repository, pass --no-lead-maintainer with every --add-maintainer or --remove-maintainer.

A lead handover needs the proposed lead to publish the complete current roster before the outgoing lead points forward.

Leaving and following

ngit repo follow-lead      # keep your history, follow a changed lead or roster
ngit repo leave            # end your own role and republish

Inspecting before you repair

ngit repo --offline

Alongside the usual metadata this reports members, lead_source, lead_path, pending_actions and health. Read those before trying to fix an unusual topology, and follow the specific error ngit gives you rather than republishing the announcement wholesale.

Going deeper

The protocol-level model — coordinate discovery, announcement ordering, and the full impersonation analysis — is documented in the ngit repository at docs/architecture/maintainer-model.md.

Next

• Repositories — hosting and metadata
• Accounts & keys