IssueTracker

Thank you for filing this request. A feature request has been filed with our engineering team and any update(s) will be posted here.

Hey Sai, it's Jesse again.

To help you immediately I have a bit of a workaround: if you're looking at a particular issue, the big red CREATE ISSUE button has a drop-down with some helpful shortcuts including "in same component," "blocked by current issue" and so on. This doesn't trigger on search results because searches can be quite complex, e.g. "componentid:187065+ -componentid:187164" for public-visible issues or "componentid:187168 OR componentid:187149" for BQ *and* DF issues (plenty of folks use both, so the issues end up all over)

Do the issue-level shortcuts work for you, or are you looking for something a bit smarter?

Yeah, I saw that dropdown. And of course I can (and did) just fill in
the form manually; it's a UX / annoyance issue, not a usability block.

I think it's poor UX for two reasons:
1. the big "create issue" button should have a smart default, which I
think is "same component as I'm looking at now", not "blank"
2. the dropdown doesn't show up, as you note, in the context of a
search (e.g. looking at all BQ issues) — even if it's a one-component
search.

I get that the search can be multi-component. But we're only talking
about having a default more intelligent than blank — one which'll be
human-reviewed before submission anyway — not a direct setting.

If the search is one-component, this is a non-issue. Just use that component.

If it's multi-component, I'd suggest that you just use the
ontologically most deep component ID in the current search. (E.g. GCP
> BigData > BigQuery is ontologically deeper than GCP > BigData.)

Or have a this-trumps-that hash, e.g. listing that 187065 is
preferable to 187164 if both might apply, etc. (This would also help
nudge issues to be filed in a preferable component ID, which is
probably good for organization overall and would save some time
re-tagging issues.)

If the current search has multiple equally-deep / preferable component
IDs, then either pick the first one or give up and leave it blank. It
doesn't have to be perfect or fully covering. It'd be an improvement
for it to just prepopulate the easy cases, and I'd bet 99% of
situations would fit the simple heuristic above.

Thanks for getting back to us

Re UX #1, thousands of Googlers use the issue tracker and they probably won't want to move too many people's cheese[1] but we could definitely surface this more, especially in single-issue view but maybe in searches too (read on...)

Re UX #2, this probably wasn't considered as a use case when the drop-down got added, but it occurs to me that if a search mentions multiple components we could *probably* just include them in a dropdown. If you'll excuse my bad ASCII art, I'll use "componentid:187168 OR componentid:187149" as an example of how this might look:

CREATE ISSUE v
            in "BigQuery"
            in "Cloud Dataflow"

[1] https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F if you're not familiar

Re #2, that sounds like a good start. I like your ASCII art. ;-)

An even better one would be to send those options along when you hit
the big 'create issue' button without dropdown, and on load, show them
in the component dropdown (as if it were an autocomplete response).

That way you can just click the big red button (no fiddling with the
two-click only-sometimes-available dropdown), click once in the
intelligently pre-populated autocomplete dropdown (or not click
anything, if it was a one-component context that can just fill it in
without an extra click), and write the report.

It only saves a few seconds of routinized actions per entry, but
multiply by #1 and that's probably significant. :-)


(I totally get the cheese thing. I'm part-time fully blind, and people
messing with my object permanence is actually a major day to day
issue. Ditto for construction or the like that makes me have to
navigate a path I'm not familiar with. Cf.
https://s.ai/essays/blindness)

Ok

Ok