Skip to main content
Robust governance depends on clearly separating high-level platform configuration from day-to-day development responsibilities. This article maps specialized administrative roles (for example, billing managers and moderators) alongside the five standard repository permission roles so you can design a secure, least-privilege governance model.
A slide titled "Robust Governance" with two side-by-side boxes. The left box says "Platform configuration — High-level" with a shield icon, and the right box says "Development tasks — Everyday" with code brackets.
The pattern is simple: start at the top with enterprise- and organization-level responsibilities, then descend to repository-level roles. This makes it easier to assign the right people the right privileges and minimize blast radius when something goes wrong. Administrative roles Enterprise-level roles
  • Enterprise owner
    • Full control over the enterprise account and all organizations beneath it.
    • Can perform organization-wide configuration, access control, and administrative tasks.
  • Enterprise billing manager
    • Scoped to finance: can manage payment methods and view invoices.
    • Cannot access repository code or change repository settings.
Organization-level roles
  • Organization owner
    • Full control of the organization, including repositories, teams, and organization settings.
    • Can add or remove owners and change organization-wide policies.
  • Organization billing manager
    • Manages the organization’s billing and invoices without access to repository source code or settings.
  • Organization moderator
    • A highly specialized, non-administrative role focused on community health.
    • Duties include hiding disruptive comments, locking heated threads, and blocking abusive users.
    • Does not receive repository or organization administration privileges.
A presentation slide titled "The Organization Moderator" describing a highly specialized role focused on community health. It lists duties like hiding disruptive comments and locking heated threads, and notes administrative power is not included.
Quick reference — administrative roles Repository roles — the ladder of trust At the repository level, GitHub provides five standard permission roles. Treat these as progressively more trusted rungs, from least to most powerful.
  1. Read
    • Can view and clone the repository and participate in conversations (issues and pull requests).
    • Cannot modify issue/PR metadata beyond participating in discussions or push code.
  2. Triage
    • Can organize the project: apply labels, assign issues, open/close issues, and manage issue and PR metadata.
    • Cannot push commits or create branches.
  3. Write
    • The standard developer role: can push commits, create branches, and open/submit pull requests.
    • Can review and participate in the code workflow, but cannot change higher-level repository settings.
  4. Maintain
    • Intended for technical leads and release managers: can merge PRs, manage releases, and maintain many repository settings and workflows.
    • Performs day-to-day operational tasks but cannot always perform destructive or organization-wide admin actions (for example, transfer or delete organization resources in some contexts).
  5. Admin
    • Full control over the repository: change branch protection rules, modify settings, transfer or delete the repository, and manage access for other users.
Repository roles — summary table
Key distinctions to remember:
  • Billing managers (enterprise or organization) can manage billing and view invoices but do not have access to repository code.
  • A team maintainer manages team membership and team-level settings; a repository maintainer (role: Maintain) manages repository operations like merging and releases.
  • Triage is the highest repository role that cannot push code; Write is the role that grants push access.
Governance checklist (practical tips)
  • Use organization-level owners sparingly and prefer team-based admin delegation for routine tasks.
  • Assign billing manager roles to a dedicated finance account, not to developer accounts.
  • Use Triage for community managers and moderators who should manage issues without write access.
  • Reserve Admin for a small group of trusted operators and use audit logs to monitor admin actions.
Links and references

Watch Video