Unshipped work is work not done

Shipping is 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 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.