KPIs

• Less than x10 the number of core team developers open (at this moment 5x10=50)
• No PRs without a label.
• All PRs with a category label: “bug”, “new feature”, or “enhancement”

Labels

• You can find the list of the available labels under GitHub labels. We replicate them across all the repositories.
• A pull request or issue might have primary labels prefixed to the title. This is explained in more detail in the following section.

PR title

• The title might have up to three primary labels. These are prefixed to the title in brackets: [primary-label] Title.

  For instance, the primary label of this issue is [slider]

  

  https://github.com/mui/material-ui/issues/44851

• The primary labels must match with an existing GitHub label, keeping the same format. For instance, use [docs] and not [Docs], as the GitHub label is lowercase docs: docs.

• The primary labels must have the following order, depending on their category: [*product scope*][*artifact*], the categories being:

  • Product scope: ‣
  • Artifact: And the important sub-label when relevant, e.g. docs, blog, website, component: YyyY.

  When multiple labels are relevant to apply (e.g., base-ui and material-ui), then add both from the broader to the most specific (e.g., [base-ui][material-ui]).

• We allow the use of React component names when relevant:

  1. If it's about a specific React component or function, you can use the JS export name e.g., [TreeItem] Fix missing type context
  2. If it's broader than one specific React component, use the component name (not the React component name), e.g., [tree view] Add virtualization as the GitHub label is component: tree view.

• Please use the same guidelines for writing a pull request title as you would use for the git commit messages https://chris.beams.io/posts/git-commit/. Mainly, the title should stay short, use the imperative mood, have primary labels, and a description.

PR description

• If the changes are trivial, like a 1-line change typo fix, the description can be omitted.
• If the issue is meant to solve a specific GitHub issue, always link it with Fix #1234.
• If the issue is related to a specific GitHub issue, for example, it's one step toward solving it, always like it with Related to #1234.
• Any developers (e.g., customers) must be able to understand from the description the following:
  • What problem are we solving? e.g., it can be detailed or come from a link to the GitHub issue
  • What are the key design decisions? For instance, what are the alternative options, and why do we ignore them?
• This is important for future scrutiny, peer reviews, clarity of thinking, and users’ trust.

PR formatting guidelines

Fixing regressions

When you open a pull request that fixes a regression, follow the steps below to ensure great history tracking of what happened and make the author who initially introduced the regression aware of what caused it and what can fix it.

1. Add the type: regression label.
2. Add to the PR description the link to the PR that introduced the regression—for example, “Regression introduced by #1234”—and ask the PR author for a review.