Issues, boards & milestones
Project-scoped planning: issues, Kanban boards, milestones-as-sprints, time tracking, and shared labels.
Scope#
Issues, labels, and milestones are scoped to a project, not a single repository — an issue can reference any repository within its project, and a milestone's progress aggregates issues across all of them. This models the common case where a feature spans a backend repo and a frontend repo but is tracked as one unit of planning work.
Issues#
Markdown body and comments (same GFM-based renderer as everywhere else), labels, a single assignee set, and an optional milestone. Cross-references resolve automatically: #123 links another issue or PR in the same project, and @username in a body or comment both links the user and creates a mention notification.
Boards#
A Kanban board groups a project's issues into status columns; dragging a card updates the underlying issue's state. The sidebar's top-level Board entry aggregates across every project you have access to, for a cross-project view of your own work in flight.
Milestones & the roadmap#
A milestone bundles issues behind a target date; its completion percentage is derived live from closed vs. total issue count, not maintained as a separately-edited field. The organization-wide Roadmap renders every milestone with a start or due date, across every project, as a single Gantt-style timeline — useful for spotting cross-team scheduling conflicts that a single project's milestone list wouldn't surface.
Time estimates, time logging, and velocity#
Every issue can carry an estimate (in minutes) set up front, and any project member can log time against it as work happens — each log entry is its own row (user, minutes, an optional note, a timestamp), so an issue's total spent time is a sum over real entries, not a single field someone has to remember to update.
Treat a milestone as a sprint — give it a start date and a due date, work it, then close it — and the project's velocity view (surfaced on the project's Insights page) reports, for each of the last several closed milestones: how many issues it contained, how many closed, and the total vs. completed estimated minutes. Charted across milestones, that's a velocity trend, computed the same way whether you call the milestone a "sprint," a "release," or nothing in particular — there's no separate sprint entity to create, start, or close beyond the milestone itself.
Labels#
Defined per project (not globally, and not per-repository) so the same label vocabulary applies to every issue and PR across every repository in the project.