Choosing what counts as in-progress

Deckgauge never asks anyone to log time — it infers hours from how long an issue sat in each status. Which statuses count as "working" is therefore the single most consequential setting in this section, and it's split across two screens at two different scopes. Conflating them is the most common mistake users make.

Per org tree: pick the active statuses and set the daily cap.

What it does, and where the data comes from

An issue's transition history is a sequence of statuses over time. The engine turns that into hours by summing how long each issue sat in a status that counts as "in progress" — everything else (To Do, Done, Cancelled, …) contributes nothing by default. Two screens control that set, at two different scopes, and one precedence order resolves between them.

Per org tree — /settings/timesheet-statuses?tree=<orgTreeId>

Pick the statuses that mean active work for this org tree. The timesheet shows and counts only time spent in these statuses — everything else, including Blocked and Code Review, is hidden entirely from that tree's grid and report. This is a hard filter, not a hint: an unselected status contributes zero hours, full stop, for every person in the tree. The same screen sets a daily hours cap (default 8h; 0 = uncapped) that bounds how much time any one engineer can accrue in a single calendar day, so a ticket left open overnight or through a weekend can't inflate a day past physical capacity. Visiting bare /settings permanently redirects here — there's no separate settings landing page.

Leaving a tree unconfigured (no row saved) keeps it on the default behaviour described below. Saving an empty active-status list is different and deliberate: it explicitly counts nothing for that tree.

Per role and per person — /timesheet/status-rules

This screen is unrelated to the org-tree picker above — it doesn't filter what's visible, it decides which statuses count as in-progress for the fallback calculation each person falls back to when no org-tree override applies. Two buttons create rules: Add role rule and Add employee override. Either way, the in-progress statuses for that rule are typed into a single field as a comma-separated list, placeholder In Progress, In QA.

A role rule and a per-person override, entered as comma-separated status names.

Precedence

For a given person, the resolution order is:

1. Org-tree active statuses — if the tree has a saved config, it wins outright for everyone in it; role and employee rules never apply on top.
2. Employee override — if the tree has no config, an EMPLOYEE-scope rule for that specific person wins next.
3. Role rule — a ROLE-scope rule matching the person's role, matched case-insensitively.
4. Default — no rule at any level: the name-based fallback below.

Under the hood: the default is name-based, not category-based

With no org-tree config and no matching rule, Deckgauge checks the status's category first and only falls back to its name if the category isn't "In Progress" — preferring the category when it's trustworthy, falling back to the name when it isn't. In practice this reads as purely name-based for Jira, because every historical transition's category lands as Unknown: the category check never fires, so the name rule — "is this status name something other than a known To Do or Done state?" — decides everything. Any status that isn't on that fixed exclude list counts as in-progress by default. That includes a brand-new status a team recently added, or one that's misspelled: it silently counts as work rather than being ignored. A provider whose transitions do carry a real category (ADO, GitHub) can have that category decide instead, ahead of the name rule.

The reason is a data-quality limitation, not a design preference: Jira's changelog carries no status category per historical transition — every past transition's category lands as Unknown. The status category field can't be trusted for history, so the engine falls back to the status name, which is reliable. Per-role and per-employee rules (and the org-tree active-status list) exist precisely to override this default wherever it's wrong for your workflow.

The default not-in-progress names

Matched after lower-casing and collapsing dashes, underscores, and repeated spaces to a single space (so "Refining - Product" and "refining_product" both match "refining product"). These sixteen names, and no others, are excluded by default — everything else counts as in-progress:

A worked example

PLAT board has no org-tree timesheet config and no status rules. An issue moves To Do → In Progress → Code Review → QA Ready → Done. Under the default: To Do and Done are excluded by name; In Progress, Code Review, and QA Ready all count, because none of the three matches an excluded name — QA Ready is not the same string as ready for qa analysis. If Code Review shouldn't count as active engineering time, that team needs either an org-tree active-status list that excludes it, or role/employee rules that name only the statuses that should count.

If it looks wrong

Related

• Working practices these numbers depend on — the process habits that keep the underlying spans honest.
• Timesheet — how the resolved status set turns into hours.
• Report: CapEx & OpEx — where the resulting hours get classified and costed.

Last updated 17 August 2026