As a repository maintainer you are responsible for the access permissions of other users to your repository.

How GitHub Works

• A repository is either Private, Public or Internal visibility. In Flutter-Global, all repositories are Private which means all permissions are explicitly assigned.
• You can assign read, write or admin permissions on a repository to a user or team. These GitHub docs explain what that means.
• GitHub allows you to group users into teams. You can manage your own teams in Flutter-Global, or use existing teams managed for you.
• Flutter-Global org owners manage GitHub Apps that grant access to your repository to 3rd party or internal systems (e.g. SonarCloud or Jenkins).
• GitHub provides a user interface for you to manually configure access. It doesn’t provide any mechanism for you to manage repo access at scale (e.g. 100s of repos). You should use the in-house Codebase Governor tool to do this.
• A small group of those who support you have access to your repository in addition to the permissions you specify.

Access Models

We recommend you choose one of these access models:

Name	Access
Inner Source: Open Contribution	All members of Flutter-Global have write access to contribute. Maintainers with admin access review all changes.
Inner Source: Requested Contribution	All members of Flutter-Global have read access. A contributor team has write access. To contribute, a user must request to join this team. Maintainers with admin access review all changes.
Closed Source: Requested Access	A reader team has read access. A contributor team has write access. To contribute or view the repo, a user must request to join one of these teams. A team of maintainers have admin access.
Closed Source: Maintainers Only	Only repository maintainers with admin access can view or contribute.

Note that the purpose of Flutter-Global is cross-divisional collaboration. Maintainer, contributor, or reader teams often have members of different divisions. For divisional work you don’t want to share, use your divisional GitHub org.

Your choice of access model depends on your context:

• Open Contribution is best for inner source repositories used by many teams with contributions from many users. It allows all Flutter-Global members to use the repository code. It reduces the effort to contribute with default write access. It’s easy to setup. However, general write access means threat analysis of your review, approval and CI workflow is critical to reduce risk.
• Requested Contribution is best for inner source repositories used by many teams which have a small, clearly defined contributor group. It allows all Flutter-Global members to use the repository code. It increases the effort to contribute by requiring an access request. It’s harder to setup than Open Contribution because you must manage your own contributor team. However, limited write access helps you manage the risk of any known weaknesses in your security controls.
• Requested Access is best for closed source repositories with sensitive content. You must manage your own reader & contributor teams. By restricting all access to the repository to only those who request it, you have reduced the risk of repo content leakage and any known weaknesses in your security controls.
• Maintainers Only is best for closed source repositories used by a single user or small team with high trust. It’s easy to setup and is low risk as no-one other than you or a few colleagues has any access to the repository.

Use Codebase Governor to configure any of these access models for your repository.

Users, Teams & Apps

You grant access to your repositories to GitHub users & teams. The Flutter-Global org owners manage the access of GitHub Apps on your behalf.

Most GitHub users are actual people. If you’re not sure who someone is, you can look them up in the service catalogue. Some GitHub users (and all GitHub Apps) are service accounts for automated access. While org owners manage GitHub apps on your behalf, you are responsible for the access of any GitHub user acting as a service account.

There are 4 types of teams in Flutter-Global:

1. The org owners manage Org teams for you. For example, you can use the all-flutter-global team to reference all members of the org.
2. You can use Codebase Governor to manage Capability teams. For example, you can group several repositories together into a capability and define a team of maintainers.
3. Each division manages Divisional teams in your divisional org. We synchronise some divisional teams into Flutter-Global for you to reference.
4. You can manage your own Self-Managed teams via the GitHub UI or API.

Read more about teams in Flutter-Global here.

Org Roles

To support your use of Flutter-Global, we grant 2 teams org roles which allows them access to your repository.

Security Managers

We grant some divisional InfoSec and GitHub support staff read access to your repository. We use the GitHub Security Manager feature to do this. This role also grants them access to edit the security alerts on your repository.

You can see this team in your repository settings:

Org Owners

The inner source team support the Flutter-Global GitHub org. To perform our role, we’re GitHub org owners.

As owners of Flutter-Global, we’ve admin access to your repository. We take this responsibility very seriously and only use this access when required. If we can redirect a support query or required change to a repository maintainer we do so.