Standardize and improve GitHub issue workflow

[chadwhitacre]

Problems

Here are problems with the current system:

1. We have a different system in different repos (sentry vs. SDKs) for no good reason.
2. We have a different setup between Support team (routing) and other teams (triage) for no good reason.
3. We conflate workflow (Status: Backlog Status: In Progress) with what we actually care about, which is whether or not we are responding to users in a timely fashion.
4. We're only paying attention to the initial response and not to follow-ups.

Proposal

Team = org members + "Outside Collaborators"
Community = everyone else

• Modify labels.
  • Rename the Status: Needs More Information label to Waiting for: Community.
  • Create a Waiting for: Team label.
  • Drop all other Status: * labels.
    • Teams that want to use GitHub for workflow should use Projects, not labels.
    • P.S. Teams that want to use Jira for workflow should use syncing.
  • Create a Trigger: Buy Time label.
• Adjust automations.
  • New tickets from Community in all repos get Waiting for: Team.
    • Team members who file tickets on behalf of Community can manually apply Waiting for: Team + Team: *.
  • New tickets from Community in all repos get a default Team: *.
    • sentry ⇒ Team: Support
    • sentry-docs ⇒ Team: Docs
    • SDKs ⇒ Team: $SDK
      • Busy SDK teams can ask Support to take over default duties.
    • etc.
  • Same turnaround for Waiting for: Team across the board.
    • Start with 16 business hours.
    • Ratchet down to eight.
  • Slack bot annoys Team: * when in Waiting for: Team state.
    • Team manually removes Waiting for: Team to stop.
    • Team manually applies Waiting for: Community if appropriate.
    • It's fine to have no Waiting for: * label. Passively waiting for new comments.
  • Team can apply Trigger: Buy Time to slow down Slack notifications.
    • After two weeks, ping.
    • After one more week, ping.
    • After one more week, ping daily.
    • After one more week, back to hourly.
  • Stale bot closes Waiting for: Community tickets (on same schedule as current) but no others.
  • New comments from Community in all repos result in Waiting for: Team.
    • If no Team: * assigned (created by Team?), assign to default Team: *.
  • Team manually applies Waiting for: Community.
• Replace 401 with a new dashboard.
• Add an automation so that when tickets are assigned to teams they go on a project board.

[BYK]

Just one observation: us vs them can create unnecessary psychological divide during interactions. Also since labels are visible to anyone, "waiting on: them" does not really convey on whom the ticket is blocked on. How about "Waiting on: Sentry Personnel" and "Waiting on: Issue Author" or something along those lines?

[chadwhitacre]

Yeah, fair enough. How about Waiting for: Sentry and Waiting for: Customer or User? Don't want them to be too long.

[BYK]

How about Waiting for: Sentry and Waiting for: Author then?

[chadwhitacre]

What about subsequent commenters, though? Author usually means OP.

[BYK]

Waiting for: Community? Dunno, I usually prefer/think the OP owns the issue and if there's someone else starting to drive it, maybe it should be a new issue? Author certainly feels better than User to me and not everyone here are "customer"s. User/Customer also breaks the "community" feel for me (might be intentional from your end)

[chadwhitacre]

Not intentional, "Community" might be it! 🤔

[chadwhitacre]

Maybe even Waiting for: Company and Waiting for: Community, since "Sentry" kinda refers to both? But then "Outside Collaborators" are included in the former, so maybe Waiting for: Team since we have Team: Foo labels?

[chadwhitacre]

Probably overthinking it, Waiting for: Sentry and Waiting for: Community should work.

[BYK]

Strong +1 to Waiting for: Team which also includes potential unpaid contributors/maintainers

[chadwhitacre]

I've updated the ticket description to use Team and Community. 👍

[chadwhitacre]

Think through value of first response vs. subsequent (cf. how we track in Zendesk).

[chadwhitacre]

Stale bot closes Waiting for: Community tickets (on same schedule as current) but no others.

Comments from Slack, in support of ☝️.

is it possible to have stalebot disabled for issues associated with projects (or a specific project)?
we're running a project on github, and it's a starting to comment on old tickets https://github.com/orgs/getsentry/projects/55/views/5
we could just mark everything as backlog but it seems unnecessary

[chadwhitacre]

Moving to #89.