When to use Q&A and how to raise awareness

[martinkrulltott]

I create a couple of Q&A discussions (example), but then @Mohammer5 pointed out that I should create JIRA tickets directly instead (example). Not sure what the best practice is here, how do I judge if something goes to Q&A or directly to JIRA? (some of my previous discussion topics, which I initially thought were bugs, ended up being “per design” and not resulting in a JIRA ticket or action taken in the end)
Also, if I post things directly to JIRA instead, should I then send a message with the ticket here? Or how do I know if / when this has actually been seen? At least in Q&A I the response time is fairly quick and seen things are noted with 👀 or a comment. But do we have something similar in JIRA? I don’t want my tickets to just get lost in the back of the JIRA closet forever, especially 1 week before the 2.36 soft freeze, so some feedback process would be needed.

[Mohammer5]

I'd say when it's clearly a bug, you can create an issue right away (like the Modal one).

some of my previous discussion topics, which I initially thought were bugs, ended up being “per design” and not resulting in a JIRA ticket or action taken in the end

I think if it's not documented anywhere, neither in the UI docs nor in the design system docs, it could be classified as a bug until the design system updates

---

How to raise awareness is a different issue though.. So good question.

[martinkrulltott]

when it's clearly a bug

How do you define clearly in this context? What's clear to me (as mentioned above, my previous discussion topics where "clearly bugs" to me but you guys disagreed) won't always be clear to you and vice versa...

[amcgee]

If it's not clear to the user, it's a Q&A!

[Mohammer5]

for the "when it's clearly a bug" part, define “clearly” please

Clearly to me means: Something is not working as it should:

• (Unexpected) behavior is not documented anywhere (e. g. UI docs & design system)
• And - when user facing - would also "cause confusion" on the user's side

For example: Both is given for the "clicking above the Modal does not close it" issue

[varl]

It might be a known issue that we consciously decided wasn't a problem "right now", and then later when we get questions about it, will cause us to have to reconsider that "now is the time to fix it" since it is affecting people in the wild.

This is hard, so opt to ask if it is difficult to figure out based on available documentation and issues in the tracker.

[amcgee]

I think anything that's at all ambiguous and/or urgent should be a Q&A topic. A valid resolution of the Q&A topic is to create a Jira issue and "resolve" the discussion topic, but if there's a deadline on the resolution of that bug it needs to be clearly noted and the Jira issue prioritized accordingly - or worked on directly by the on-call tappster. This is why we have the rotation.

[amcgee]

Maybe the discussion should stay open until the bug is fixed, even, so that subsequent support rotations can pick up the work? Not sure about that.

[Mohammer5]

I think anything that's at all ambiguous and/or urgent should be a Q&A topic

Big agree on the ambiguous part.

---

About urgent, I'm not so sure, should be handled by the product mangers, right?

[amcgee]

(imo)
In this case it is being handled by the product manager (of the team using the library, i.e. Scott for Analytics) saying a particular feature is needed in 2.36 - the on-call support dev should be able to work on smaller issues and/or push them into the larger Platform queue if they are too big to work on in a support role (and informing the consuming team/PM when this happens)

[Mohammer5]

informing the consuming team/PM when this happens

Wouldn't that be the job of the PM of the team of the issue reporter? The on-call support dev could pick that up (e. g. when the other team has been notified on slack) if no one responds for some time

[varl]

Wouldn't that be the job of the PM of the team of the issue reporter?

If we can work across teams (developer-to-developer) without always "flagging up" that's a leaner process for everyone, and will lead to less frustration and higher throughput. In my view a developer has a lot of autonomy to decide what s/he works on as long as it aligns with the overarching priorities.

The Team Lead and Product Manager are two parts of a whole; the PM focuses on the functional domain and the TL focuses on the technical domain and together they come up with the high-level priorities.

Developers spend their days with the code and there is no one more suited to do low-level prioritization on a day-to-day basis. A developer takes architecture decisions all the time when working on code and are trusted to do so ("this needs to be refactored", "this needs more tests", "this module can be removed/moved to better serve the whole", to name a few).

Ideally the PM/TL steers in a direction (the "what"), and the Team figures out the "how" and the "when". It is all a feedback loop though, to which the Team is a most important contributor.

A developer is free to work on "things that come up" even if they are not tagged or prioritized by a PM/TL. The key is that the work is visualized and if there is a risk that it is going to affect the high-level priorities of the Team, then at least the TL needs to be informed.

The Q&A barrier to entry should be 2 on a 0-10 scale. If you have a question -- ask it.

... After checking the docs and issue tracker; that's where the "2" comes from.