Unshipped work is work not done

Shipping some value is always the top priority, always. If we ship and people use our product then we can worry about making it better. If no one uses our product, you'll have no code to write.

Undocumented solutions are as-if no solutions exist

Developers use the documentation to find solutions to their problems. They don't run a treasure hunt in the source. A problem without documentation is a problem unsolved, it's work not done. Developers should also consider undocumented API as private, which might break without following SemVer.

The smaller a pull request is, the better

All pull requests should be single-focused (solve one problem at a time). If you wonder if two changes belong together, then the answer is almost always no. There are two exceptions for bundling changes together:

• The change is trivial, meaning, we could ask any member of the team, and he will be able to understand the full scope of the change by looking at the git diff.
• The change is a simple refactor with no API implications.

The why https://github.com/mui-org/material-ui-x/pull/1319#issuecomment-811786628

Pull requests should be reviewed

We value reviewing PRs, almost all of them: https://sophiebits.com/2018/12/25/why-review-code.html.

We can merge trivial changes alone or we can also merge if we have asked for a review that nobody provided within 7 days. (signals no bandwidth)

Definition of Done

Best to be done in the same pull request, but for large problems, it can be done in multiple chunks.

• The feature is OK’d by stakeholders. For instance, the product owner/manager, but a customer can also be involved, confirming that the changes are fixing his problem.
• Changes are peer-reviewed (approved by another member).
• The documentation is up-to-date and comprehensive.