Purpose TL;DR

Product experts resolve technical issues and problems for our users & customers, while improving the self-serviceability of our products and making them better.

Who performs this function?

Every product engineer.
‣ team

GitHub issues

The primary focus of the GitHub issues is to keep a live product backlog.

Maintainers accept support questions on GitHub as new issues if they can be turned into product improvements. In this case, we add the support: question labels on the GitHub issue.

Support - Tier 1

This is about routing the incoming new community issues and PRs to the right person in our team. It’s about not notifying everybody but giving ownership to individuals: ‣.

KPIs for success:

To help with **‣ (0 GitHub issues/PRs with no labels)
- Issues without labels: 0 https://tools-public.mui.com/prod/pages/issuesWithoutLabels
- PRs without labels: 0 https://tools-public.mui.com/prod/pages/prWithoutLabels
To help with ‣ (0 GitHub issues: "status: waiting for maintainer" label)
- Issues without product scope label: 0 https://tools-public.mui.com/prod/pages/issueWithoutProductScope
- ”status: waiting for maintainer” issues without assignee: 0 https://tools-public.mui.com/prod/pages/needtriageNotAssigned
To help with ‣ (Community: unique contributors per month) This number is a bit unclear since it includes a lot of open PRs that come from the renovate bot and are outdated.
- Open PRs without reviewers: 35 https://tools-public.mui.com/prod/pages/openPrWithoutReviewer

Issue status

See how the state of the GitHub issue matches with ‣ shared terminology:

New.
Open. Have the label status: waiting for maintainer until the issue is categorized
Pending. We use the label status: waiting for author
On-hold. There is no specific handling, no label.