Migrate triage from issue labels to project metadata

[chadwhitacre]

GitHub has two systems for organizing and managing issues: listing/labels (old) and project/metadata (new). The latter has the following advantages:

1. Projects are decoupled from repos. Whereas labels are tied to a single repo, projects are at org-level, providing for processes that span multiple repos.
2. Projects are decoupled from each other. There's only one set of labels for a given repo, which means that multiple processes operating on the same set of issues in a repo have to share the label namespace, leading to clutter and confusion. An issue can live in multiple projects, so it can participate in unrelated processes without clutter.

Since we don't want the same issue participating in both label-based and project-based processes simultaneously, the way to do this is to implement from the end back, so that the last thing to do is switch over which process new issues go into. I've set up a new Community Engagement board, AKA "76.".

• Modify notify-for-triage to subscribe to issues by product area in 76.
• Auto-add new issues created by non-eng to 76 (no product area and "Waiting on: Support" status) instead of "Status: Unrouted" label.
• Update internal and external docs.
• Update (duplicate?) Looker dashboard 401.

We can't subscribe to project-related events directly from the getsantry app config, but we can set up a webhook.

Since this switches from teams to product owners it addresses part of #90 as well.

[chadwhitacre]

I'm learning that some teams use their own project boards to stay on top of triage (vs. just Slack notifications). We need to think through how to get issues onto their boards and how to support their needs, some use the status labels.

https://github.com/orgs/getsentry/projects/31/views/7

https://github.com/orgs/getsentry/projects/47/views/1

[hubertdeng123]

Looks like we can't rely on status in the customer engagement board to get issues onto their boards. It feels like we can still use both the status labels and project statuses at the same time for the time being

[chadwhitacre]

We need both labels and project metadata. We don't have unlimited issues in projects, that's one thing.