Initiatives and products

Many teams work along two axes at once. On one side there are repositories: the frontend, the backend, the API… They are permanent, never close and get maintenance all the time. On the other there are goals with an end: “the ordering website”, “the cloud migration”… They have a start and a finish, are split into milestones, and their issues are built in one repository or another.

If each issue can only live in one project, you have to choose: follow the goal (“how much is left?”) or follow the repository (“what’s pending in the API?”). With project kinds you don’t have to choose.

Why did we add it? A complete case tells the story, with screenshots and videos: a team with its API, website and app in separate repositories and a goal that cuts across all three. Read it in Three repositories, one goal with a deadline.

Project kinds

• No kind. What every project has when it’s created, and it works as always. If you don’t work this way, there’s nothing to do.
• Initiative. A goal with an end. Its issues are delivered to the products where they’re built.
• Product. A code project: a permanent repository (or product). Besides its own maintenance issues, it receives the ones initiatives deliver to it.

Set the kind from the project menu in the sidebar (right click) or in the Kind row of the project page. In the sidebar, each initiative shows a target and each product a box.

The kind is final

Once set, it can’t be changed or removed. Hilbana warns you before confirming. It’s final because deliveries depend on it: a product with delivered issues that stopped being one would leave them nowhere. Before choosing, think whether the project is a goal that will end (initiative) or a repository that will stay (product). The General project can’t have a kind.

Delivering an issue to a product

The page of an initiative issue shows a Product field. You pick it in two steps: first the product and, if it has milestones, which one it goes into. The field shows both together, for example “apirest · v2.3”.

• The issue still lives in the initiative: its identifier doesn’t change (for example WEBS-12), and branches and PRs keep linking the same way.
• It also shows up in the product: in its list, its board and its page, with the “from WEBS…” tag. An All / Own / Delivered filter separates its own issues from the ones it receives.
• It counts in both milestones: the initiative’s (say, “Phase 1”) and the product’s (“v2.3”). Each milestone’s progress and AI summary include it.
• It shows from the initiative too: on its list, the Product column tells you which product and version each issue goes to (“apirest · v2.3”), and on its board every card carries the same tag. You can hide the column from Columns.

You can also pick the product when creating the issue, from the form in the initiative’s list.

One issue, one repository

Each issue is delivered to a single product. If an issue touches two repositories (front and back), split it: the Split by repository button on its page creates one sub-issue per product you choose, already delivered to its product. If one depends on the other, relate them with blocks.

Who sees and does what

Whoever has access to a product sees the issues delivered to it, even without access to the initiative. They see those issues, not the whole initiative: not its other issues, milestones or documents. On the issue page, the initiative shows by name, without a link.

If they can also write in the product, they build them: change their state, comment, log time and put them in a product milestone. What they can’t do is edit their content (title, description, priority, assignees…) or change which product they go to: that belongs to whoever runs the initiative.

Blocks across repositories and agents

When the back issue blocks the front one, the front agent (or person) can’t start theirs too early:

• The agent queue (next_ready_issue) doesn’t hand out a blocked issue.
• claim_issue rejects it and says which issue blocks it and in what state it is.
• get_issue shows each relation with the other issue’s state. If it can’t see it, only its identifier and state.

As soon as the back issue is done, the front one enters the queue. Over MCP, next_ready_issue and list_issues accept a product’s projectId and also return what’s delivered to it. More in API and MCP.

Automatic delivery from the PR’s repository

On a product’s page, the Repos row declares its GitHub or Bitbucket repositories. A repository can only belong to one product.

When a PR from one of them arrives linked to an initiative issue that has no product yet, the issue is delivered automatically to that product, and a comment explains it. If the issue already went to another product, it isn’t changed: a comment is left so someone can review it.

Limits

• Everything works within the same workspace: an initiative doesn’t deliver issues to products in another workspace.
• Only initiative issues are delivered to a product.