- A PR is a conversation about code, not just a means to an end to add code to a repository
- A well written PR should be re viewable by a novice/junior programmer
- A PR is best when it is short, has a clear focus, and contains a clear commit history
- A developer should consider how a given commit will appear in a diff to those reviewing the code
- A dev team should have a 'social contract' that defines how they are going to communicate and what things they are going to care about as a team.
- A dev should strive to make other devs 'code switch' as little as possible by writing code that falls into an agreed upon standard deviation for the team.
- A feature branch merged into main, stage, or test environments should not negatively impact the applications ability to run correctly in any way