Scenarios for teams

Below are proven “role + scope + individual adjustments” combinations for typical situations. Switch names are as in the interface (“Permissions” → “Advanced”).

A small team, one project

Developers run their own tasks from setting them to review; the tech lead approves other people’s formulations, sends work back for rework and publishes PRs/MRs.

Several projects, different teams

Give each member grants only on their projects. Those responsible for everything get Maintainer on the whole organisation. A person on two teams gets two grants: for example, Maintainer in shop and Contributor in bot. This way nobody sees projects they have nothing to do with.

External contractor

Contributor · Project (or · Repository, if only questions about the code and research are needed). The contractor runs their own tasks and sees the project’s context, but does not publish PRs/MRs, run audits or touch repositories. When the work is over, remove the member: access to the organisation’s repositories goes away together with the grants.

Reviewer without the right to publish

Contributor · Project plus, under “Advanced”:

• “Resolve and dismiss findings — other people’s tasks”
• “Send for rework — other people’s tasks”

The reviewer works through findings and sends tasks back for rework, while “Approve” — publishing to the source repository — stays with the Maintainer and the owner.

Customer or product manager

Contributor · Project — sets tasks, answers clarifications on them, approves the formulation of their own tasks, follows the review and the cost. If they should also approve the formulations of tasks set by the team, turn on “Approve the formulation — other people’s tasks” and “Answer clarifications — other people’s tasks”.

A department without code

One space per department, grants only on it:

Employees ask questions and order research on the department’s documents, see colleagues’ conversations in the space and read its knowledge base; the Maintainer writes rules, facts and pitfalls and changes other people’s conversations. Support does not see the HR space, and sales does not see support’s: everyone has grants only on their own space. Documents are connected to the space by the owner together with an IT specialist — what to ask for; a selection by department is in Recipes by role.

An author who publishes themselves

By default a Contributor does not approve even their own tasks. For a mature team where the author takes a task all the way to a PR, turn on “Approve and publish PRs/MRs — own tasks”. Other people’s tasks still remain with the Maintainer.

Observer: view only

Contributor on the scope needed, with these turned off:

• “Create tasks”
• “Submit tasks for work”
• “Ask questions”
• “Create research”
• “Add findings”

Such a member sees tasks, reviews, audits, conversations and research, but starts nothing and spends no balance. Suitable for a manager, a finance person, a process auditor.

Code auditor

Contributor · Repository (or · Project) plus, if needed, “Run audits and tools preparation”. The auditor asks questions about the code, does research and runs the audit without touching tasks.

An on-call person who can stop everything

Contributor · The whole organisation plus “Stop, resume and close — other people’s tasks”. The person on call can stop any run without getting the other Maintainer permissions.

How to check the setup

Open “Members”: the member’s chip shows the role, the scope and the number of individual adjustments (“2 changed”). Press “Permissions” → “Advanced” — the switches that are on are exactly what they can actually do in that scope. What exactly the member will see on each screen is described in What a member sees.