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 Ticket status 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.
• Solved. The issue is closed.
• Closed. We rarely lock issues, but sometimes we do when the community needs to be directed to a different place.