Chapter 3. The Most Important Role, and the First Step: Trusted Committer
TL;DR
For projects with any level of risk, you need to have a Trusted Committer. Define the role’s responsibilities clearly, based on the level of risk.
Trusted Committers shift back and forth between coding and Trusted Committer responsibilities.
The Trusted Committer role is difficult, and you need to reward those employees who deserve and accept the role.
The rewards to the enterprise are great: better integrated code, better code reviews, faster pull request (PR) turnaround time, clearer knowledge for refactoring, more documentation with less pain, and bottleneck reduction.
In the previous chapter, we described some of the cultural problems we’ve encountered. Codebase owners must accept pull requests, or they create bottlenecks and escalations up the management chain. External teams must learn and conform to the style and standards of the codebase to which they are contributing, or their contributions must be extensively rewritten. And when codebase owners and external contributors don’t work together, nothing gets better and everyone ends up discouraged.
Many of the problems stem from the fact that developers in the enterprise environment are often unwilling to dedicate time to reviewing and accepting pull requests or mentoring developers in other areas. And who can blame them? They typically have assigned tasks and goals that are specific to their own project, not to other projects that happen ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access