Migrate Customer Feedback flows to public GitHub

[chadwhitacre]

Right now Customer Support, Customer Success, and Sales/Solution Engineering funnel customer feedback into a private Jira board. We want to redirect this flow into public GitHub so that we can have one source of truth shared by both internal and external stakeholders. We also want PM to use GitHub to collect feedback from users.

This is (still) part of Back to Our Roots.

Exhibit A

This is what we want to normalize:

getsentry/sentry#39329

1. Customer A files a ticket.
2. Normal routing/triage flow, quick enough initial response.
3. Customer B notifies CSM of same issue, provides great info privately.
4. CSM writes up a detailed, anonymized comment on the public ticket.
5. Eng responds quickly with a solid answer.

To Do

• PM
  • Resolve inefficiency in posting new Discussions in sentry #38
  • Is Build in Public our framework? #75
  • Write Notion docs for PM #74
  • Announce on Vanguard.
• COPS
  • Set up GitHub ⇔ Jira connector #63
  • Write Notion docs for CSM/SE #80
  • Grant Triage role to CSMs/SEs.
  • Train everyone.
    • Kick-off session for CSM/SE
    • Add GTM to the onboarding session.
    • 1:1s where needed.
  • Level up Customer Support #83
  • Enable routing for GTM teams #86
  • Update 401 dashboard for GTM
  • Announce on Vanguard.

[chadwhitacre]

This ticket is a little late, we've been working on this for a couple months. Here's the internal notion doc that is the focus of discussion for a group of nine internal stakeholders. tl;dr We're splitting this up into two parts, first focus is Customer Support, later wave will be CSM/SE.

[chadwhitacre]

Customer Support is redirecting feature requests to GitHub as of Oct 6.

Conversations evolving with Product Management as they are the properly the true owners of GitHub backlog.

CSM/SE in the wings.

[chadwhitacre]

@dcramer in #triage-product (private Slack channel):

Hey folks, while its still top of mind, can we make sure we are creating GitHub issues for all problems we're escalating to this channel? We have gotten into the habit of using Slack as a massive "can you do this" context switch, but that does not scale, and w're trying to push this accountability into the public eye to grow trust.

@rbisol re: getsentry/sentry-ruby#1891

eng is pushing support to move issues to github, which creates problems when we need to provide specific customer information, such as links to events/projects, screenshots, repro-videos….
feedback and feature requests were moved to GH
we already had two issues with it:

• one i didnt notice PII in the screenshot and had to have it removed from github after customer complains
• the entire issue contains only user information, the GH issue is just a link to Jira -> redundant and the contractor the Mobile team put to work on it has zero visibility.

@dcramer:

That’s feel solvable. We did this when we started Sentry and nothing about the business has changed. Let’s just avoid screenshots and instead create bug reports with the appropriate details. If a customer decides they want to add a screenshot that’s totally fine.

@souredoutlook:

Just hoping to have part of this clarified:

can we make sure we are creating GitHub issues for all problems we're escalating to this channel?

Are you asking us to post a link to a GH issue in this thread instead of articulating the bug report directly in Slack?
Our (support) current process is:

• identify customer issue
• reproduce
• articulate bug report in this thread
• if going into backlog -> create a Jira issue as request by member of EPD

If you want us to switch to:

• identify
• repro
• open GH issue in revelant repo
• cross-post to this channel

That will take some adjusting and likely a little bit of enforcement. please let us know 🙂
My initial understanding based on convo we had with Chad about this previously was we were just swapping the last part of our process from Jira to GH

@dcramer:

The issue is two fold:

1. Putting feature requests on GH won't achieve the company's goals alone
2. The ever pressing concern: we have about 30 slack channels that engineers are responding effectively to support tickets in (including an other other Slack instance). This is constant context switching from folks getting pinged and causing thrash. Sometimes this is fine when its an emergency, but we're relying on Slack as a crutch right now.

My ask is to 1) Improve the GH usage (find a way to generate useful tickets, just as if a customer would if they were submitting it themselves), as this will help our strategic community goals as well as customer UX, and 2) we'll continue to push for a focus on those curated tickets/reports vs the onslaught of real-time feedback requests.

it certainly won't remove the need for this channel, but pretty much every #discuss-X channel has become a variation of that at various times of the day.

I'm mostly aiming to solve (1), and do it in a faster time horizon than we have traditionally approached changes to the org.

So to answer your question specifically, I'd say yes I'd love to see that second process adopted in the near term. Basically open the issue and link it in Slack - as that will give ample context to the developers when they need to look at it, and it creates some initial push of the GH utilization. Ultimately we need to find a way to resolve "this is urgent" vs "in our normal triage process someone should look at this minor concern".

[chadwhitacre]

I wrote a draft vanguard post Ripping off the GitHub band-aid and am vetting internally.

[chadwhitacre]

Aiming for Nov 1 publish date.

[chadwhitacre]

Expecting to do training into Q4.

[chadwhitacre]

ATO is Nov 1, will need to bump a week. 🐭

[chadwhitacre]

Big meeting, resulted in #63 and buy-in from GTM. 👍

[chadwhitacre]

Had an impromptu 1:1 with enterprise CSM mgr, gaining traction and identifying positives/wins for team (better responsiveness from EPD).

Unito seems to be emerging as the option on #63.

Exploring Build in Public with PM leadership—is this our framework? 🤔

Starting to coalesce ...

[souredoutlook]

@chadwhitacre - noticed this upcoming step:

• Update teams in Notion and on website.

It looks like our documented structure and team labels and EPD structure have drifted from one another. Example: there is no longer a workflow team in EPD. Issue Experience team has slightly different goals, some of which are coalescing with ecosystem. 🐭

Let me know what I can do to help with that, thinking:

• draft PR for open.sentry.io , and
• a process for deprecating labels or managing label migration in GH.

[chadwhitacre]

noticed this upcoming step

Heh, yeah, I added that after yesterday's Slack thread. I forgot to circle back! 😅

If you get to the PRs before I do, by all means, go for it!

[chadwhitacre]

Shipped!