Decision

<aside> ✅ Option: Option B. We have a Toolpad app ‣. The idea is to label everything with product scopes. The only way to scale. Why?

</aside>

Context

For a couple of months, we have tried to introduce a Duty Support Engineer like MUI X has ‣ to make this flywheel open core flywheel spin in MUI Core. However, this initiative had the opposite effect desired:

• Our support metrics went up:

  

  https://master--toolpad.mui.com/deploy/cl6rqzry10009arlv9sto6qja/pages/cl6rqzryv0001arlv7mtjdj1u - https://ossinsight.io/analyze/mui/material-ui

  While the volume of monthly new issues didn’t increase, decreased a bit actually.

• People in the team struggled to get enough context on the large product history that Material UI is. This struggle leads to:

  • Less enjoyable work for maintainers
  • Slower responsive time for the community
  • Sub-optimal product decisions as lacking enough context on why the previous decisions

So instead, we decided to reproduce what works with MUI X: small teams focused on specific components. It’s how our competitors operate. It’s why @Michał Dudak made https://github.com/mui/material-ui/pull/33995

This shaping is about exploring how to make the best of it.

Problems

• @Danail Hadjiatanasov mentioned how MUI X can’t use assignments based on the code pathname because there are too many variations to consider.
• CODEOWNERS only works with PRs.
• CODEOWNERS doesn’t capture docs changes: https://github.com/mui/material-ui/pull/34060#issuecomment-1226337991

Options

A. GitHub Action to assign maintainers on issues & PRs

B. Toolpad app to only show relevant issues & PRs

Something to replace the GitHub issue and PR views.

‣

Solved with ‣

Proposal

Option: