I frequently work with a parent issue that has a number of child issues. For each child I need to answer two questions at a glance:
Does this child have a workspace? (a child with 0 workspaces has had no dev environment launched and likely needs attention)
Has more than one workspace accidentally been launched for this child? (a duplicate is easy to create by mistake)
Today, answering either question requires opening each child issue individually and manually checking how many workspaces exist inside it. When there are many children this is slow and error-prone — the very mistakes I'm trying to catch (a missing workspace, or a duplicate) are the ones I'm least likely to notice while clicking through issue after issue.
Showing a workspace count inline, next to each linked issue, makes both questions answerable without leaving the parent issue.
Proposal
When an issue lists linked issues, display the number of workspaces associated with each linked issue directly beside it.
Display / emphasis
0 workspaces: no special emphasis (normal state).
1 workspaces: slightly emphasized, so it is immediately clear at a glance that a workspace exists.
> 1 workspaces: shown with a warning treatment, to draw attention to a probable accidental duplicate.
The distinction between > 0 and 1 is important: > 1 is the common, expected case and should be quick to confirm, while > 1 is the anomaly that deserves attention.
Performance considerations
The count is over workspace entities explicitly owned by / created from an issue, not a re-evaluation of arbitrary saved queries. As such it should be answerable with an indexed COUNT(*) GROUP BY issue_id over the set of visible linked issues, rather than per-issue query evaluation. This keeps the added cost proportional to the number of linked issues shown, not the number of workspaces or the size of the system.
The count must not degrade the page load of the parent issue even when it has many children.
Dynamic updates
The count must stay up to date without requiring a page refresh — for example, when a workspace is created or removed for a child issue, or when the child is added/removed as a linked issue, the displayed number should update on its own.
This needs to be done in a way that does not compromise UI/UX speed or stability: updates should be incremental and scoped to the affected linked-issue entries, not trigger a full reload or re-render of the issue page.
Acceptance criteria
Each linked issue shows its associated workspace count inline.
Count of 0 is displayed without special emphasis (or not displayed at all).
Count 1 is slightly emphasized
Count > 1 is shown with a warning treatment.
Counts update dynamically without a page refresh when relevant workspaces are created/removed.
Dynamic updates do not cause a noticeable slowdown or instability of the issue page, including for issues with many linked children.
Motivation
I frequently work with a parent issue that has a number of child issues. For each child I need to answer two questions at a glance:
0workspaces has had no dev environment launched and likely needs attention)Today, answering either question requires opening each child issue individually and manually checking how many workspaces exist inside it. When there are many children this is slow and error-prone — the very mistakes I'm trying to catch (a missing workspace, or a duplicate) are the ones I'm least likely to notice while clicking through issue after issue.
Showing a workspace count inline, next to each linked issue, makes both questions answerable without leaving the parent issue.
Proposal
When an issue lists linked issues, display the number of workspaces associated with each linked issue directly beside it.
Display / emphasis
0workspaces: no special emphasis (normal state).1workspaces: slightly emphasized, so it is immediately clear at a glance that a workspace exists.> 1workspaces: shown with a warning treatment, to draw attention to a probable accidental duplicate.The distinction between
> 0and1is important:> 1is the common, expected case and should be quick to confirm, while> 1is the anomaly that deserves attention.Performance considerations
The count is over workspace entities explicitly owned by / created from an issue, not a re-evaluation of arbitrary saved queries. As such it should be answerable with an indexed
COUNT(*) GROUP BY issue_idover the set of visible linked issues, rather than per-issue query evaluation. This keeps the added cost proportional to the number of linked issues shown, not the number of workspaces or the size of the system.The count must not degrade the page load of the parent issue even when it has many children.
Dynamic updates
The count must stay up to date without requiring a page refresh — for example, when a workspace is created or removed for a child issue, or when the child is added/removed as a linked issue, the displayed number should update on its own.
This needs to be done in a way that does not compromise UI/UX speed or stability: updates should be incremental and scoped to the affected linked-issue entries, not trigger a full reload or re-render of the issue page.
Acceptance criteria
0is displayed without special emphasis (or not displayed at all).1is slightly emphasized> 1is shown with a warning treatment.