sinraWhat is an Issue?
An issue represents a concrete piece of work: a bug to fix, a task to build, a specification to write. Every deliverable in Sinra traces back to an issue.
Unlike traditional “user story” formats with rigid structure, Sinra issues use direct, descriptive names. “CSV export for reports” is more useful than “As a user, I want to export reports so that I can analyze data.”
Issue Types
| Type | When to use | Status it carries |
|---|---|---|
| Specification | Says what must be verified: the requirement, written down | Writing status |
| Plan | Optional. Says how the specification will be built | Writing status |
| Task | A unit of implementation work | Development status |
| Bug | A defect to fix | Development status |
The type is chosen when the issue is created, from the New menu, and it cannot be changed afterwards. The global New button creates a bug.
Specifications, plans, tasks and bugs all follow the same planning rules: they can sit in a capability, a release and a cycle. What differs is the status they carry, how they count in capacity, and which links they accept. The traceability page explains how they connect.
Core Fields
- Name: concise, descriptive title
- Body: rich text with images and
@mentions - Priority: Low, Medium, High
- Estimated time: in days, feeds capacity calculations
- Labels: custom tags per organization
- Platform: Backend, Frontend, Mobile, etc.
Assignment
Issues can be assigned to a specific user or to an entire team. When assigned to a team, any team member can pick it up.
One Status per Type
An issue carries exactly one status, the one that matches its nature:
| Type | Status | Why |
|---|---|---|
| Specification, plan | Writing status | They are written, reviewed and approved |
| Task, bug | Development status | They are implemented, tested and closed |
The form, the issue page and the lists only show the status that applies. A new issue starts at the initial status of its type.
Realization
A specification or a plan never has a development status of its own. Instead, its realization is calculated from its tasks and shown next to its writing status:
| Realization | When |
|---|---|
| Not started | No task yet, or every task is still to do |
| In progress | At least one task has started, but not all are done |
| Done | At least one task, and all of them are done |
The realization comes with the count of tasks done out of the total (for example 2/5). A specification counts all its tasks, those attached directly and those under its plans. You never type the realization: it follows the tasks.
“Done” for a specification is therefore two separate questions: is it written (writing status) and is it built (realization). A cycle counts the first one.
Design Chain: the Parent Link
A plan or a task can say which issue it carries out, through its Parent issue:
- A plan has a specification as parent.
- A task has a plan or a specification as parent.
- A specification and a bug have no parent.
The parent is always optional, and parent and child are always in the same capability. Choosing a parent attaches the issue to the parent’s capability. If a parent moves to another capability, its children follow.
The issue page shows the chain as a tree: the ancestors, the issue, then its plans and tasks, each with type, name, status and realization. A specification page shows how many tasks are done out of the total, and an Add a plan or Add a task action opens the creation form with the parent and the capability already filled in.
Deleting in a Chain
Deleting never leaves an orphan:
- Deleting a plan that has a specification as parent: its tasks move up and attach to the specification.
- Deleting an issue whose children have nowhere to go (a specification with plans or tasks, a plan without parent that has tasks) is refused. The message gives the number of attached issues. Move or delete them first.
Release and Wished Release
An issue in a capability always has the release, and the wished release, of that capability. Both fields are read-only on the form and show where the value comes from (“Inherited from” the capability). An issue without a capability chooses its release freely. See Releases for the full rule.
Concerns: a Link for Issues Outside a Capability
A bug found after delivery cannot enter the capability it comes from: it would take a release already shipped. An issue without a capability can instead declare the capability it Concerns. This link is informative only: it changes neither the release of the issue nor any progress, load or capacity figure. It disappears as soon as the issue is attached to a capability.
Time Tracking
Log time spent directly on an issue. Sinra compares spent time against the estimate, surfacing overruns before they become surprises. These numbers feed the cycle workload calculation. The time is saved as soon as you leave the field (Enter, Tab or a click elsewhere) and a short confirmation appears. A negative value is refused with a message, and what you typed stays in the field.
Your Role on an Issue
A person can be linked to an issue in four ways: assigned to it, assigned through their team, its creator, or its tester. “My issues” shows the first one by default and lets you pick another.
Choosing a Capability from a Past Release
The capability selector of an issue offers every capability, including those of a past release, which come last and carry a “Past release: v0.9” mark. Choosing one makes the issue follow that release, as for any capability.
Duplicate Warning
When you create an issue, typing a title of at least 8 characters looks for open issues with a close title, whatever the word order (“Follow-up badge company” finds “Company badge: follow-up”). A warning links to up to three of them, each in a new tab. It never blocks anything: you can still create the issue.
Comments and Mentions
Each issue has a threaded comment section with rich text and @mentions. Mentioning a user triggers an email notification with full context. Discussion stays attached to the work, not lost in Slack.
Mentions land in your notification center: the counter in the top bar, a link that opens the exact comment, and a Waiting for a reply box to follow questions until they are answered.
The Publish button posts the comment; an empty comment, or one with only spaces, is refused with a message (an @mention alone counts as content). In the @ menu, press Enter or Tab to insert the highlighted person without losing what you typed; deactivated members are not offered. Long comments wrap instead of being cut off.
The type of an issue is set at creation. When you edit an issue, it is shown read-only.
Created from an Action
An issue can be created from an action of a retrospective or a postmortem (Convert to issue). The form arrives pre-filled and fully editable: title, a link back to the origin, type (a task from a retro, a bug from a postmortem), assignee, release and cycle. The issue page then shows “Created from the action … of …” with a link, or “origin deleted” if the retro or postmortem no longer exists.
From then on the action follows the issue: done when the issue is finished, abandoned when it is deactivated, back to in progress when it is reopened. Deleting the issue gives the action its previous status back and removes the link. An action converts into one issue only: converting it again creates the issue without a link and tells you so.