Recommended settings for organizations with diverse teams
This page describes the recommended configuration for organizations consisting of multiple, content-wise different teams – for example, various research groups, project teams, or departments. The goal is for team maintainers to manage membership in their teams independently, while the organization administrators (Owners) retain overarching control.
Core principles
- Control access through teams, not through individuals.
- Set base permissions to No permission or Read.
- Designate a Maintainer for each team who independently manages team membership.
- Org admins (Owners) invite new members to the organization; team maintainers then assign them to teams.
Step 1: Configure base permissions
The organization's base permission is set to No permission or Read. The choice affects administration. Generally, Read is easier to implement since all organization members automatically have read access to repositories.
If you choose No permission, it is recommended to maintain a team with all members so that read permissions can be granted through the team.
- Navigate to
Settings→Member privileges. - Set Base permissions to
No permissionorRead. - Click
Save.
Step 2: Create teams for each group
A separate team is created for each research group, department, or project. Descriptive names are recommended (e.g., team-bioinformatics, team-teaching-cs).
Recommended team visibility: Visible, so that all organization members know the teams and can @mention them if needed. For confidential groups, Secret can be chosen.
→ Guide: Teams
Step 3: Designate team maintainers
Each team is assigned at least one person as Maintainer. The Maintainer is responsible for:
- Adding and removing existing organization members from the team.
- Maintaining the team description and team name.
- Managing the team's repository access.
Important: Team Maintainers can only add people to the team who are already members of the organization. Inviting new people to the organization is exclusively reserved for organization administrators (Owners).
To make a person a Maintainer:
- Open the team and switch to
Members. - Click
...next to the member →Change role→Maintainer.
Step 4: Grant repository access through teams
Repositories are not assigned directly to individuals but exclusively to teams. This greatly simplifies administration: when a person changes teams, their access rights automatically adjust.
Recommended permission levels per role:
| Use case | Recommended level |
|---|---|
| Read access (e.g., viewing documentation) | Read |
| Active collaboration on a project | Write |
| Project leads with configuration rights | Maintain |
| Team takes full repository management | Admin |
→ Guide: Teams – Configuring repository access
Step 5: Process for new members
Since only organization administrators can invite new members in GHES and GHEC, the following process is recommended:
flowchart TD
A[New member needs access] --> B[Team Maintainer reports need to Org Admin]
B --> C["Org Admin invites person via People → Invite member"]
C --> D[Person accepts invitation and becomes Org member]
D --> E[Team Maintainer adds person to team]
E --> F[Person has access to team repositories]
→ Guide: Inviting members
Step 6: Team hierarchies for large organizations
For organizations with many teams, parent teams can be used to logically group teams (e.g., a parent team team-research with sub-teams team-bioinformatics and team-genomics).
Benefits:
- @mentioning the parent team notifies all sub-teams.
- Structures the team overview more clearly when there are many teams.
→ Guide: Teams – Team hierarchies
Summary of recommended settings
| Setting | Recommended value |
|---|---|
| Base permissions | No permission/Read |
| Repository access | Depends on Base permissions |
| Team visibility | Visible (exceptions: Secret) |
| Team Maintainer | At least 1 per team |
| Inviting new members | Only by Org Admin (Owner) |
| Adding external collaborators | Only by Org Admin (Owner) |