Roles on a team and where you fit
Beginner Core Git
Why this matters
"Ask a maintainer", "get a review", "DevOps will deploy it": the workflow is full of roles, and the roles decide who can press which button. Knowing them tells you whom to ask, and it tells you what your own role is expected to do and not do.
The roles
| Role | What they do | In Git terms | Typical platform role |
|---|---|---|---|
| Developer | Writes and changes source code and tests | Branches, commits, pushes, opens merge requests | Developer / Write |
| Reviewer | Reads other people's changes and comments; any team member can be one | Comments and suggestions on a merge request, approval | Developer / Write |
| Maintainer (also lead, code owner) | Responsible for main: decides what gets merged, protects branches, cuts releases |
Approves and merges, creates tags, configures the project | Maintainer / Maintain |
| Owner / admin | Administers the group or organization: members, billing, security settings | Rarely touches code | Owner / Admin |
| QA / tester | Verifies behaviour, writes bug reports, sometimes automated tests | Checks out branches, runs the program, files issues, may push tests | Developer or Reporter / Write or Triage |
| Technical writer | Writes and maintains documentation | Branches, commits Markdown, opens merge requests, reviews docs | Developer / Write |
| Product owner / manager | Decides what is built and in which order | Creates and prioritizes issues, reads merge requests and boards | Reporter / Triage |
| DevOps / platform engineer | Runs the pipelines, environments and deployments | Edits .gitlab-ci.yml and workflows, deploys, rolls back |
Maintainer / Maintain |
| Designer | Produces the look and the interaction | Often works outside Git; sometimes commits assets | Reporter or Developer |
| Support | Talks to users, reports what they see | Files issues, reads release notes and history | Reporter / Triage |
The platform role (the last column) is what GitLab or GitHub lets you do: read, write to branches, merge into protected branches, change settings. Lesson 9.3 and lesson 10.3 list the exact permissions; for now remember the ladder: Reporter/Triage can read and manage issues, Developer/Write can push branches and open merge requests, Maintainer/Maintain can merge into main and change settings, Owner/Admin can do everything.
Where you fit
You are probably one of these:
- Documentation contributor. You behave exactly like a developer whose files happen to be Markdown: branch, commit, push, merge request, review. You need the Developer (Write) role. Ask the maintainer for it; there is no reason to give a documentation writer less.
- Tester. You need to fetch other people's branches and run them, and to file precise issues. Developer (Write) if you also push tests; Reporter (Triage) is enough to read and file.
- Analyst or scripter. Developer (Write) on the repository where your scripts live, which may be a separate one from the product.
- Product or project. Reporter (Triage) on the product repository is usually enough: issues, boards, milestones, reading merge requests. You rarely need to push.
- Support or operations. Reporter (Triage) for issues plus read access to history and releases; Developer (Write) if you apply hotfixes.
Whatever the hat, three habits make non-developers welcome in a repository: work on a branch, keep merge requests small, and answer review comments quickly.
How to ask
- For access: the maintainer or owner of the project. Say what you need to do ("open merge requests for the docs"), not the role name; they will pick the right role.
- For a review: the person who owns the area you changed (CODEOWNERS files name them), or whoever the team's convention says. Assign them on the merge request rather than messaging privately.
- For a deployment or a release: the maintainer or DevOps, through the team's usual channel; never by editing production yourself.
- For help with Git: anyone; but bring the output of
git statusand the exact error message (lesson 13.9).
Common mistakes
- Asking for Maintainer "to be safe". More permission means more ways to break things and more responsibility. Developer is the right level for contributing.
- Reviewing only code. Documentation, test data and configuration changes need review too; ask for it and offer it.
- Bypassing the maintainer for a hotfix. Even urgent changes go through the workflow, faster. The hotfix workflow is in lesson 13.2.
Try it yourself
Goal: identify the roles in the playground's team.
- Read the "Team" paragraph at the end of the playground's
README.mdand the "Merge requests" rules inCONTRIBUTING.md. - Decide who can merge into
main, who reviews Ana's documentation, and which platform role each person needs.
Expected result: one maintainer, several developers, and a rule of one approval before merging.
Show solution
Dev is the maintainer (approves, merges, protects main). Ana (writer), Ben (developer) and Chloe (QA) need the Developer role. Any of them can review; the CONTRIBUTING rule asks for one maintainer approval, so Dev approves Ana's documentation changes, possibly after Ben reviewed the technical content.