Further reading at: Technical Support

The Community Engineer (CE) is meant to allow other team members to focus on the areas of their product without needing to switch context too much on product areas they don't own/know. We use the round-robin mechanism where a different person is the CE for the week, responsible for the following things:

• Make sure that each new issue has the correct labels that correspond to the area the issue is about and assign it to one of the maintainers of that area based on Product owners. The assigning can be automated with GitHub action once we set the rules for how the action should work. KPI link: https://github.com/mui/material-ui/issues?q=is%3Aopen+is%3Aissue+label%3A"status%3A+needs+triage"+no%3Aassignee
  • *(Note: we currently receive help from Greg, who handles the first touch on the issues; however, it is still the responsibility of the CE ***to make sure that the labels are applied correctly and all issues are assigned)
• Make sure that each new pull request created has the correct labels that correspond to the area the pull request touches and that there is a request for review from one of the owners of that area (see Product owners ) KPI links: ‣, https://github.com/mui/material-ui/pulls?q=is%3Apr+is%3Aopen+no%3Alabel
  • (Note: we currently receive help from Greg, who handles the first touch on the PRs; however, it is still the CE's responsibility to ensure that the labels are applied correctly and all PRs are reviewed).
• Handle all dependency updates pull requests created by renovate or appropriately label with “on hold” the ones that cannot be immediately merged. KPI link: https://github.com/mui/material-ui/pulls?q=is%3Apr+is%3Aopen+label%3Adependencies+-label%3A"on+hold"
• Do the release once the community support week is finished (on Monday the following week).

<aside> ⚠️ Days off. When you take days off, please make sure to transfer the ownership to someone else.

</aside>

Success KPIs for the team

1. By the end of the week, there shouldn’t be any issues that have the **“status: needs triage” label and are older than 24 hours.** This should ensure that we are actually looking into the created issues. Would be great if we could create a practice where this is a daily activity of the maintainers.
2. By the end of the week, there shouldn’t be any open pull requests from the community that haven’t received an initial response. This Toolpad app can help a bit [To help with Community: unique contributors per month 📊 (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.](https://mui-org.notion.site/To-help-with-Community-unique-contributors-per-month-This-number-is-a-bit-unclear-since-it-incl-c58d3a81abbf408aa8bf17bb77fbb870).
3. By the end of the week, there shouldn’t be any issues with no label assigned and are older than 24 hours. This ensures no issues go under the radar, as it sometimes happens when the “status: needs triage” label isn’t applied automatically.