The GitHub organisation model

Nothing about the alma-mobility-marketplaces organisation is configured in the GitHub UI. Teams, who is in them, what each team can reach, and the settings on managed repositories are all Terraform, in github-iac. A drift workflow runs against the real organisation and reverts changes made by hand.

That has one consequence worth arriving with: you get access by opening a pull request, not by asking an admin. An admin clicking it for you produces access that disappears on the next drift run. You edit YAML, not Terraform, and a plan on the pull request shows what would happen.

Everything else about it — the four config files and their fields, how to add someone to a team or allowlist an Action, the validation rules, the reasoning behind the team model — is in github-iac’s own documentation, which is the thing that stays current. This page does not restate it.

Why our CODEOWNERS files name two teams

This one belongs here, because it is a convention you have to follow in every repository without github-iac being the place you would think to look.

Each domain has a parent team for @mentions plus -write / -admin children, and access is granted to the children only. A CODEOWNERS line naming the bare parent therefore requests review from a team that cannot approve. So our CODEOWNERS files name both children, which together are that domain’s internal roster. This site’s own CODEOWNERS is a worked example.

Do not trust a list of team names, including any on this page

Two summaries of the domain list are stale. The organisation profile page names an nx-platform team that does not exist (the real one is m1-platform), and github-iac’s team-naming reference still describes autotalli as planned when its teams exist. config/teams.yaml is the authority — read it rather than any summary. Checked 2026-09-02.

GitHub Advanced Security is not licensed here

Code scanning, secret scanning, push protection and private vulnerability reporting are GitHub Advanced Security features, and the organisation has not bought the licence. So they are unavailable to us as platform features, and that absence is why we run our own scanning — see how supply-chain security works.

Dependabot alerts, security updates and the dependency graph are enabled per repository by github-iac, so nobody configures them by hand. If a repository predates those defaults, open a pull request there rather than toggling settings in the UI.

Dependabot version updates are not part of that. They only exist where a repository carries its own .github/dependabot.yml, so they are opt-in per repo — most usefully to keep SHA-pinned actions current.

Not documented here

Who to ask about anything — team rosters, ownership, on-call — is in Confluence MONE. People and process change for social reasons rather than technical ones, which is why they are not in a repository at all. Where documentation lives has the full split.