Reconnecting…
Waiting for the connection. It is taking a while. Reload the page
This page hit a problem
It is reconnecting and will carry on from where it was.
Projects
A project holds tickets under a short key, and a ticket moves through a workflow you define, with every change recorded field by field. Plan on kanban and scrum boards, rank the backlog, group work into epics, release against versions, and keep the code's commits and pull requests on the tickets they mention. The module every team uses; the other three build on it.
One unit of work with a type, a status, a priority, a reporter and an assignee, and a page that holds the whole conversation around it.
The New ticket dialog opens over any page, with the same fields the edit form shows. On the ticket page each detail is changed where it is shown, and a form that somebody else saved under you keeps what you typed and says what they changed.
In the guide →Comments in Markdown, restricted to a role or a group when they must be, files that go straight to storage, watchers told of every change, mentions, votes, and who else has the ticket open right now.
In the guide →Who did what and when, with the old and new value of every field, comments, transitions, files, links and logged time, and the commits that mention the ticket.
In the guide →Sub-tasks break work into steps and an epic gathers the tickets of a larger piece; the parent counts what is done and adds up the time. Links relate tickets with typed relationships, recorded on both.
In the guide →Text, numbers, dates, selects, users, versions and more, scoped to the projects and ticket types that need them, required where they must be, on the form, the page and in search.
In the guide →A level limits who sees a ticket to named people, groups, roles, the reporter or the assignee. Tickets outside your level are left out of every list, board, queue and search.
In the guide →Statuses and the transitions between them are data, not code. A transition can be limited to certain people, checked before it completes and followed by what should happen next, and it can ask for a resolution, an assignee or a comment. Each project and ticket type can work its own way, and a workflow imported from Jira runs as it did there.
Statuses with a category
To do, in progress or done, so boards and reports know what each status means.
Transitions between them
Named moves from one status to another, or from any status, in the order people see them on the ticket.
Rules on each transition
Conditions on who may run it, validators on what must be true first, post functions on what happens after.
A workflow per type
Each project chooses its ticket types and the workflow each one uses.
A board shows tickets as cards in columns, one column per group of statuses, drawn from one project or several.
Kanban boards for continuous flow and scrum boards that show one sprint at a time, with columns you arrange, work-in-progress limits and done tickets that leave the board after a while.
In the guide →Drag a card to another column and the workflow decides where it may land; or select a card and run a transition from the panel beside it, where the whole ticket page is.
In the guide →A ticket with sub-tasks, or an epic with tickets, becomes a lane headed by the parent. Collapse the lanes you are not working in; the board remembers.
In the guide →Drag tickets into sprints and into order, or plan from the keyboard with a Move to menu. The order on the backlog is the order on the board.
In the guide →Create a sprint with a goal and dates, start it, complete it and send what is left to the next one. A ticket that leaves a sprint keeps the record that it was there.
In the guide →A burndown per sprint and velocity across the last ones, counting tickets or points from an estimation field, from each ticket's own history.
In the guide →Tickets are fixed in versions and affect versions, with release dates and what a release still waits for; components name the parts of the product and can decide who a new ticket goes to.
In the guide →Commits, branches and pull requests that mention a ticket key appear on the ticket, and a command in a commit message comments on it or moves it through the workflow.
In the guide →Membership through people or groups, each with a role that grants permissions from viewing to administering, and roles that can be held on a customer for every project billed to it.
In the guide →Every module is in every workspace, at one price per seat. A workspace takes a couple of minutes and asks for no card; an installation is one container image and a compose file.