Organizations & teams
Organizations group people and repos under a shared namespace.
A repo at acme/widget is owned by the acme org, and access
is managed through teams + direct collaborators.
Creating an org
Account menu → "New organization". You'll need:
- A name — same rules as usernames; cannot collide with an existing user or org.
- A primary email (for billing/notifications; org settings only).
The creator is the first owner.
Roles
- Owner — full admin: settings, billing, member management, any repo. There must always be at least one owner.
- Member — appears in the org's people list; sees public + the private repos a team grants them.
A user can be both an owner and a team member.
Inviting members
Org → People → "Invite member". Type an existing username or email. The invitee gets a notification + email; they accept on a landing page and become a member immediately.
Invitations expire after 7 days; resend or revoke from the same page.
Removing members
Owner → click a member → "Remove". The user loses team memberships and any direct grants the org had given them. If they authored issues/PRs, those stay; if they had pending invitations, those are cancelled.
Teams
Teams are how you grant repo access at scale.
- Create: Org → Teams → "New team".
- Members: add org members; non-members must be invited to the org first.
- Repo access: add repos with one of
read,triage,write,maintain,admin. Multiple teams can grant on the same repo; the user's effective permission is the maximum. - One-level nesting: a team can have a parent team. Members of a parent team are also considered members of every child team for permission purposes.
Mentioning a team
@acme/security in any markdown body notifies every member of
that team. Useful for review requests and triage.
Org-owned repos
Indistinguishable from user-owned repos in most ways; the difference is that access is governed by team grants instead of the owner being a single user.
Audit
Org → Settings → Audit log surfaces org-level events: member add/remove, team create/delete, repo transferred in/out, role changes. Same per-row IP + user-agent capture as the personal audit log.
View source
| 1 | # Organizations & teams |
| 2 | |
| 3 | Organizations group people and repos under a shared namespace. |
| 4 | A repo at `acme/widget` is owned by the `acme` org, and access |
| 5 | is managed through teams + direct collaborators. |
| 6 | |
| 7 | ## Creating an org |
| 8 | |
| 9 | Account menu → "New organization". You'll need: |
| 10 | |
| 11 | - A name — same rules as usernames; cannot collide with an |
| 12 | existing user or org. |
| 13 | - A primary email (for billing/notifications; org settings only). |
| 14 | |
| 15 | The creator is the first owner. |
| 16 | |
| 17 | ## Roles |
| 18 | |
| 19 | - **Owner** — full admin: settings, billing, member management, |
| 20 | any repo. There must always be at least one owner. |
| 21 | - **Member** — appears in the org's people list; sees public + the |
| 22 | private repos a team grants them. |
| 23 | |
| 24 | A user can be both an owner and a team member. |
| 25 | |
| 26 | ## Inviting members |
| 27 | |
| 28 | Org → People → "Invite member". Type an existing username or |
| 29 | email. The invitee gets a notification + email; they accept on a |
| 30 | landing page and become a member immediately. |
| 31 | |
| 32 | Invitations expire after 7 days; resend or revoke from the same |
| 33 | page. |
| 34 | |
| 35 | ## Removing members |
| 36 | |
| 37 | Owner → click a member → "Remove". The user loses team |
| 38 | memberships and any direct grants the org had given them. If they |
| 39 | authored issues/PRs, those stay; if they had pending invitations, |
| 40 | those are cancelled. |
| 41 | |
| 42 | ## Teams |
| 43 | |
| 44 | Teams are how you grant repo access at scale. |
| 45 | |
| 46 | - **Create:** Org → Teams → "New team". |
| 47 | - **Members:** add org members; non-members must be invited to |
| 48 | the org first. |
| 49 | - **Repo access:** add repos with one of `read`, `triage`, `write`, |
| 50 | `maintain`, `admin`. Multiple teams can grant on the same repo; |
| 51 | the user's effective permission is the **maximum**. |
| 52 | - **One-level nesting:** a team can have a parent team. Members |
| 53 | of a parent team are also considered members of every child |
| 54 | team for permission purposes. |
| 55 | |
| 56 | ## Mentioning a team |
| 57 | |
| 58 | `@acme/security` in any markdown body notifies every member of |
| 59 | that team. Useful for review requests and triage. |
| 60 | |
| 61 | ## Org-owned repos |
| 62 | |
| 63 | Indistinguishable from user-owned repos in most ways; the |
| 64 | difference is that access is governed by team grants instead of |
| 65 | the owner being a single user. |
| 66 | |
| 67 | ## Audit |
| 68 | |
| 69 | Org → Settings → Audit log surfaces org-level events: member |
| 70 | add/remove, team create/delete, repo transferred in/out, role |
| 71 | changes. Same per-row IP + user-agent capture as the personal |
| 72 | audit log. |