An extension of Company culture applied to engineering.
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 the product, you can delete the code.
All pull requests should be single-focused, meaning solve one problem at a time.
There is one exception for bundling changes together, If both conditions are met:
The why https://github.com/mui-org/material-ui-x/pull/1319#issuecomment-811786628
When a PR review process becomes too overwhelming, it’s a strong sign to close the PR and break it down into smaller ones, or to reduce its scope and to give up on the more ambitious changes, as they are not ready.
Go to the root. We always choose to reduce the scope of what we work on when needed so we can focus on the few things that matter, and do them right, rather than covering more ground in a half-hearted form.
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.
Leave the code better than you found it. With your changes, you are breaking things, introducing debt, you don’t know it yet, it will only be clear in hindsight.
So when you see something broken, make a debt credit by fixing it, and trust someone else will fix your code.
We value reviewing PRs, almost all of them: https://sophiebits.com/2018/12/25/why-review-code.html.