Recommended Settings

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

1. Control access through teams, not through individuals.
2. Set base permissions to No permission or Read.
3. Designate a Maintainer for each team who independently manages team membership.
4. 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.

1. Navigate to Settings → Member privileges.
2. Set Base permissions to No permission or Read.
3. 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:

1. Open the team and switch to Members.
2. 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)