Members & roles

Inviting people

Open a project's Settings → Members to see who's on the project and to invite more people.

<img class="shot-light" src="/img/help/settings-members-light.webp" alt="Settings, Members section: three members with their emails and role menus, a pending invitation marked "invited as viewer — waiting for an account", and an Ownership block for transferring the board."> <img class="shot-dark" src="/img/help/settings-members-dark.webp" alt="Settings, Members section: three members with their emails and role menus, a pending invitation marked "invited as viewer — waiting for an account", and an Ownership block for transferring the board."> Start typing a name or email — the field suggests matching accounts from the workspace directory (people already on the project aren't offered twice) — or enter any email address directly. Then pick a role.

• If that email already has a ogma account, they're added immediately.
• If not, it becomes a pending invitation. Once an account exists for that email, they automatically join the project on their first sign-in with the role you chose. (Pending invitations can be revoked from Settings.)

Either way, the new member hears about it: joining a project drops a notification into their bell.

Managing members and invitations needs the Admin role.

Roles

Roles are set per project — you can be an Owner on one board and a Viewer on another. Each role includes everything the roles below it can do.

A couple of notes:

• The person who creates a project is its Owner.
• You can invite people as Admin, Member, or Viewer. Owner isn't an invitable role.
• Viewers see a fully read-only board — the edit controls simply aren't shown to them.

Handing over ownership

The Owner can transfer the board to another member: in Settings → Members, under Ownership, pick a member and confirm. The new owner gets the Owner role (and a notification); the previous owner stays on the project as an Admin. A project always has exactly one owner. (Workspace administrators can also perform a transfer.)

Removing someone

From Settings → Members, remove a member or change their role. (Roles and removals also respect the rules above — for example, a project always keeps at least one Owner.)

Member labels

Roles say how much someone may edit; member labels say what someone is on this board — architect, analyst, developer, reviewer. They're a per-board vocabulary, curated in Settings → Member labels (create, rename, recolour, reorder, delete), and they apply to bots as much as to people.

A label is a title, and only a title. It is deliberately not the same thing as either of the board's two role vocabularies:

• your role here (Viewer / Member / Admin / Owner) is what decides what you may do, and no label changes it;
• a pool worker's role (implement / review / explore) names a shipped agent profile — which tools that worker gets — and is a fixed platform set, not something a board invents.

Keeping titles free of capability is the point: naming someone "architect" should never quietly hand them anything.

• Every board starts with four titles — architect, analyst, developer, reviewer — and is free to replace all of them.
• Admins assign labels from the Members section (the + label control on a member's row).
• Anyone may remove their own label — a title you didn't agree to isn't a title. Doing so notifies the board's admins, naming the label, so self-service stays accountable. An admin removing someone else's label is silent.
• Deleting a label someone still holds is refused, and the message names the holders. Renaming one is always free — nothing keys off the name.

Labels carry no permissions — roles still decide everything above.