Project settings#

The Admin area configures the whole instance. Project settings configure a single project: labels, workflow, visibility and connected repositories. The project's leads edit them, and so do the Team-Admins of every team that owns the project. Deleting the project, connecting Git, attaching it to another team and deciding who leads it are for the leads only. Team-Admins manage everything else but cannot appoint themselves lead. Platform admins have no rights of their own here.

Labels & workflow states#

At the heart of a project's configuration are two lists of colored, named items: labels and workflow states. Both share the same shape:

{ "id": "…", "name": "In Progress", "hue": 210 }

• name: what you see, and how issues reference the item. Labels and states are name-keyed. An issue records the name, so states and labels line up by name across the project.
• hue: the color, stored as a hue on the shared ProjectPalette. Every project gets its own consistent coloring instead of a fixed global set.

Workflow states are the columns of your board, e.g. To Do → In Progress → In Review → Done. Labels are reusable tags you attach to issues from a multi-select picker.

Draft and save bar#

Editing labels and states doesn't save on every keystroke. You edit a draft: add, rename, recolor, reorder. While you have unsaved changes, a save bar appears where you commit or discard them all at once. A half-finished rename never ripples through the project.

Members & team access#

This is also where you control who can see and work in the project. There are two ways:

• Members: people added directly to the project.
• Teams: Hinata's teams grant project access per member.

A person only sees a project that their team or a direct membership grants. The check applies app-wide. Restrict a project here and it disappears from the boards, search and reports of anyone without access.

Deadlines#

With project templates on, Deadlines count in sets whether new relative deadlines in this project count calendar days or working days. Without a choice of its own, the project follows the organization's default, which organization admins set on the Organization page. You get the same choice when you create or copy a project.

The setting only preselects what a new deadline starts with. Existing deadlines keep their own basis and do not move.

Project key#

Every project has a short key (e.g. ASTA) that prefixes its issue numbers (ASTA-42). Smart commits, branch names and PR titles use it to link work to an issue. See Git integration.

Git connections#

A project can connect one or more repositories on GitHub, GitLab or Bitbucket from its settings.

• Prerequisite: the operator has registered the OAuth apps in the Admin area.
• Only a project lead adds repositories here and configures automation rules and the branch template (both shared project-wide).
• Each connected repo keeps its own token, webhook and default branch.

Full detail is in Git integration.

How changes propagate#

• Labels and states save as a batch from the draft when you commit the save bar. The server cascades renames to existing issues.
• Access changes take effect immediately. Removing a member or a team's grant hides the project from them across the app.
• Git connections register their webhook on connect, so development info shows up on issues right away.

Where to go next#

• Projects & teams: teams, membership and visibility.
• Boards & sprints: how workflow states become board columns.
• Git integration: connect a project's repositories.