Issue Types
The issue types Elixion ships with, the fields each one uses, and how to add your own
Elixion, the platform for Engineering Intelligence™, ships seven issue types. A type does two things: it tells a reader what kind of work this is, and it decides which planning fields are worth filling in. It does not change the statuses available, and it does not change who can be assigned. Every type can go to a person or to an AI agent.
The types
| Type | What it is for | |------|----------------| | Epic | A body of work that holds other issues and spans sprints | | Story | A user facing change, described by its outcome | | Task | A piece of work with no user facing outcome of its own | | Bug | Something that behaves differently from how it should | | Subtask | A slice of a parent issue | | Spike | Time boxed investigation whose output is an answer, not a change | | Tech Debt | Work that improves the code without changing behaviour |
The create form offers Task, Story, Bug, Epic, Spike and Tech Debt. Subtask exists as a type and is reached through an issue's Subtasks section rather than from the type dropdown.
Epics
An epic is the one type with aggregation behind it. Its child issues are the issues that point at it, and Elixion computes progress over the whole child set rather than the page of children you happen to be looking at. Subtasks and nested epics are excluded from the count, so a child's own children are not counted twice.
An epic reports four numbers: issues done, issues total, points done, points total. Done means the Done status.
Epics also carry start and target dates, and a colour, which is what places them on the roadmap.
Stories
A story's useful fields are the description, the acceptance criteria and the story points.
Acceptance criteria is its own field on the create form and on the issue. Keeping it out of the description matters more than it looks: it is the field a reviewer reads to decide whether the work is accepted, and the field an agent reads to decide when it has finished.
Story points are entered with whatever estimation scale the project is configured for.
Tasks
A task uses the time fields rather than points, though it can carry both:
- Original estimate, in hours.
- Remaining estimate, in hours.
- Time spent, in hours, accumulated from work logs.
Bugs
A bug is an ordinary issue. There is no severity field, no affected version field and no regression flag. Priority carries the urgency, with values Critical, High, Medium, Low and Trivial, and the free text Environment field carries where it happens.
Put the reproduction in the description and the expected behaviour in the acceptance criteria.
Bugs move through the same seven statuses as everything else. What varies is the wording on the board: a project started from the Bug tracking template names its columns Reported, Triaged, In progress, Fixed and Verified, which sit over Backlog, To Do, In Progress, In Review and Done. You can rename any column in Project Settings under the Board tab.
Spikes and tech debt
A spike is time boxed research. Give it an estimate and state in the acceptance criteria what answer would close it, since a spike with no stated output runs forever.
Tech debt is work that changes how the code is built without changing what it does. It takes the same fields as a task.
Subtasks
A subtask has a parent issue and is created from that issue's Subtasks section. Subtasks are excluded from an epic's progress roll up, so breaking a story down does not inflate its epic.
Custom types for a project
A project can define its own issue types, at Issue types (/issue-types). Each one carries:
- A name, a short key and a description.
- An icon and a colour.
- A category, used for grouping.
- Hierarchy rules: a level, whether it can be a parent, whether it can be a subtask, and which types are allowed above and below it.
- Field configuration: which fields are required, which are hidden, and what they default to.
A custom type with no project is available everywhere; one with a project belongs to that project.
Assigning any type to an agent
Every type can be assigned to an AI agent as well as to a person. The assignee list on an issue has a Users group and an AI Agents group, and the issue records which of the two it went to. Agent options need a connected repository on the project. See Using Agents.