The 4 Is of Pull Requests
An effective code review process is able to prevent small or urgent review getting stuck behind large or non-urgent items.
Similar to how we can classify types of changes in commits, and illustrate the relationship between them using emojis, we can communicate information useful for prioritising review using pull request titles and “The 4 Is”:
Idea (Candles hurt less to look at)
How complex is the idea motivating changes in a pull request? (E.g. general and abstract concepts such as adding linting to a project are easily understood, but project-specific or nuanced bugfixes are complex and require deeper knowledge and context)
- 🕯 Simple
- 💡 Medium
- ☀️ Complex
Implementation (Small fish are easier to swallow)
How large is the changeset to implement the idea or change? (E.g. a new linting rule is a simple idea, that may result in a large changeset)
- 🐟 Small
- 🐬 Medium
- 🐳 Large
Impact (Prefer to be hit by a bicycle)
How big of an impact could the changes have? (E.g. a one-line change to a core module could be a simple idea and implementation, but have a large impact)
- 🚴️ Small
- 🚗 Medium
- 🚚 Large
Immediacy
How urgent is it to get the changeset live?
Note: This attribute is probably the most variable over time (changing priorities or the passage of time can turn a non-urgent pull request into an urgent one), and therefore most likely to require updating:
- 🗓 Not urgent
- 🕐 Somewhat urgent (sooner released, sooner value is delivered)
- ⏰ Urgent (likely already having negative effects)