Current behavior (context)

On issue and pull request pages today, Workspaces sits in the top operations/status strip — next to the issue state control (or PR status), not in the sticky side info panel.

• Issues: IssueOperationsPanel places Workspaces beside state transitions and “new issue”. The dropdown opens WorkspaceSpecListPanel (specs, create, and existing workspaces with status + owner).
• Pull requests: the same control lives in the PR status bar (tip: “Workspaces on source branch”), beside status and clone.
• Side info panel: fields, iterations, branch, votes, watches, reference, delete, etc. It is sticky on wide viewports, but can be closed; on narrower viewports it is an overlay opened via the ellipsis. It does not currently surface workspaces.
• The Workspaces button itself has no count/summary — you only see running workspaces (status, #N, user/AI) after opening the dropdown.

So the “wisdom” of the top placement is mainly: treat create/access as a primary page action that stays available even when the side panel is closed, consistent with state/status controls and with Workspaces on the code browser. The tradeoff you hit is real: the operations bar is not sticky, so checking active workspaces while reading long activity means scrolling back to the top.

Clarifying questions

Please answer with the letter options (and notes if useful).

1. What is the main pain while working an issue/PR?

   • A. Seeing which workspace is active / which AI user owns it while reading comments (visibility)
   • B. Creating or opening a workspace without scrolling to the top (action access)
   • C. Both visibility and action access while scrolled down
   • D. Something else (please describe)

2. Where should Workspaces live going forward?

   • A. Move the Workspaces dropdown entirely into the sticky side info panel
   • B. Keep the top dropdown for create/access; add a compact summary in the sticky side panel
   • C. Keep the top dropdown; make the operations/status bar sticky as well
   • D. Keep placement as-is; only add a summary badge on the existing top Workspaces button (count / AI hint)

3. What should an always-visible summary include?

   • A. Count of running/active workspaces only
   • B. Count plus AI/user identity (name or avatar)
   • C. Compact list with status + user + link into each workspace
   • D. Show any summary only when there is at least one workspace (hide when empty)

4. Where should this apply?

   • A. Issues only
   • B. Issues and pull requests
   • C. Issues, pull requests, and branch/blob pages for consistency

Pros / cons (brief) and recommendation

Recommendation: prefer 2B + 3B (or 3C if you often juggle several workspaces) + 3D empty-hide + 4B, unless question 1 is mostly “I never open the side panel” (then lean 2C or 2D).

That keeps Workspaces as a primary create/access action when the side panel is closed, while using the sticky side panel for the “who/what is running?” glance you currently scroll for.

furthermore, it would be nice if we could have next to each workspace within the workspace dropdown list, which comment , comment, triggered it. If no comment triggered it, then simply link directly to the issue or pull request.

Good addition — noted for the Workspaces dropdown list.

Current limitation

Today a workspace is associated with an issue and/or pull request, but not with a specific comment. AI task workspaces can be started from comment events (mention / relevance), field assignment, PR events, etc., and the triggering comment is not stored on the workspace. Manual create via the dropdown also has no comment. So the list cannot show a reliable “triggered by this comment” link without persisting an optional comment reference at creation time.

Your fallback (no comment → link to the issue or pull request) matches the associations we already have; the missing piece is optional comment association for comment-awakened runs.

Clarifying questions (this point)

Please answer with letter options (and notes if useful). Still happy for answers to questions 1–4 from the earlier comment as well.

5. When should a workspace count as “triggered by a comment”?

   • A. Only AI task-automation workspaces started from an issue/PR comment (mention or relevance wake-up)
   • B. Any workspace created with a specific comment in context (including future flows)
   • C. Same as A for comments; for assignment / other non-comment wakes, treat as “no comment → issue/PR link”

6. How should the comment (or issue/PR) link appear next to each workspace row?

   • A. Small icon/link that jumps to that comment in the activity stream (or to the issue/PR when none)
   • B. Short snippet/preview of the triggering comment + link (issue/PR link when none)
   • C. Prefer that secondary link for navigation; keep opening the workspace as the primary row action

7. If there is no triggering comment (field assignment, manual create, etc.), what should the secondary link do?

   • A. Always link to the associated issue or pull request
   • B. Show the secondary link only when a comment association exists
   • C. Link to issue/PR for assignment-style wakes; omit for manual create from the dropdown

Recommendation: 5C + 6A + 7A — store optional comment id for comment-awakened AI workspaces, show a compact jump-to-comment control beside each row, and fall back to the issue/PR link otherwise. That matches the “which comment started this?” need without crowding the dropdown with previews.

1. Currently workspaces are displayed at the top in order to be consistent with issue list/board.
2. Link workspaces to comments are very cubersome, as many of them are not triggered comments.

1. a, b, c
2. a. With @robin's approval. the side panel is now sticky, so it's always available, it now costs more UX energy to keep the workspaces drop down at the top.
3. c. interior, the number of workspaces is always going to be very minimal and the value of very quickly being able to see which workspace is running and how many of them are running is crucial in order to save AI tokens when they're not actually needed.
4. c
5. b
6. a
7. b

Link workspaces to comments are very cubersome, as many of them are not triggered comments.

agreed, but when they are triggered by comments, it's very helpful, especially for users who have a low-token threshold.

Thanks for answering the clarifying questions. Recording your preferences:

1. Pain: A/B/C — both visibility and create/open access while scrolled down
2. Placement: A — move the Workspaces dropdown into the sticky side info panel (pending @robin approval)
3. Summary: C — compact list with status, user, and link into each workspace
4. Scope: C — issues, pull requests, and branch/blob pages
5. Comment trigger: B — any workspace created with a specific comment in context
6. Link UI: A — small icon/link to the comment
7. No-comment case: B — show the secondary link only when a comment association exists

@robin already noted that top placement keeps consistency with issue list/board, and that workspace↔comment links are cumbersome because many workspaces are not comment-triggered.

Those notes conflict with 2A and partially with 5B. @robin — please decide:

1. Keep Workspaces at the top for list/board consistency, or move into the sticky side panel (and whether list/board/blob should follow)?
2. Invest in optional comment association + jump link in the dropdown (only when present, per 7B), or leave comment linking out?

No code change from me on this Question until that product call.

Thanks @robin — updating the earlier rationale: Workspaces stays at the top primarily for consistency with the issue list/board (same control pattern there), not only as a “primary page action.”

Also agree that linking workspaces to comments is a poor fit when many workspaces are not comment-triggered. Dropping the comment-association idea from questions 5–7 unless you want to revisit it later.

@zaakiy’s answers still prefer moving Workspaces into the sticky side panel (2A, with your approval) with a compact always-visible list (3C), across issues/PRs/branch pages (4C). That conflicts with keeping the control at the top for list/board consistency.

@robin — please decide the product direction:

1. Keep Workspaces at the top for list/board consistency (status quo), optionally only adding a summary badge on the existing control, or
2. Relocate / duplicate into the sticky side panel as preferred (2A + 3C + 4C)

I’ll hold any UX change until that call.

@robin I'm really coming at this from an improved usability point of view

Not being able to see the workplaces that are running is an encumbrance to using this platform.

Agreed that displaying workspace dropdown (together with count) at right side is more convenient. @servicedesk please create an improvement request for this.

Nevertheless, binding workspaces to comments will not be considered as:

1. Not all workspaces are triggered by comments
2. This clutters the comment list

@robin Created the improvement request: issue #2920 (assigned to you). Linked as Related.

Per your decision:

1. Workspaces dropdown moves to the sticky right-side panel, together with a count
2. Binding workspaces to comments will not be considered (workspaces are not necessarily comment-triggered; associating them would clutter the comment list)

@zaakiy Closing this question as answered — please continue any discussion on issue #2920.

@robin I do not have permission to transition this issue to Closed. Could you close it when you are satisfied with the answer / follow-up in issue #2920?

@servicedesk please summarize the benefits of doing this for me.

@zaakiy Benefits of moving Workspaces into the sticky side panel (with a count), as tracked in issue #2920:

1. No scroll-to-top — On long issue/PR pages the side panel stays visible, so you can check or open workspaces without jumping back to the top operations bar.
2. At-a-glance activity — A count next to Workspaces shows whether anything is running before you open the dropdown, which helps decide whether to start another AI session or stop one that is no longer needed (saves tokens).
3. Create/open while scrolled — Create and open stay on that same sticky control, so both visibility and action access work while you stay in the activity stream.
4. Fits sticky metadata — Workspaces sit with the other always-available issue/PR context instead of living only in the non-sticky top strip.

Comment↔workspace linking stays out of scope (not all workspaces are comment-triggered; associating them would clutter the comment list).

Does this answer your question, or do you want more detail on any point?