Trusted Committer (TC)
Think of the TC as the developer(s) in your organization, perhaps team leads, that are trusted and highly invested in the specific project. Their role is to help mentor contributors and to move code changes along. Some of their other responsibilities include:
- Writing and maintaining contribution guidelines
- Code reviews on PRs
- Maintain project dependencies
- Provide mentorship and support
- Lead discussions and help resolve issues
The InnerSource Commons details specific roles that are valuable in adopting InnerSource. Some developers must take on responsibilities outside of their silos, so they created a new role with defined responsibilities and called it the Trusted Committer.
- For projects with any level of risk, you need to have a Trusted Committer.
- 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.
Cultural problems that exist with no TCs
- Codebase owners must accept pull requests or they create bottlenecks and escalations up to the management chain.
- External teams must learn to conform to the style and standards of the codebase to which they are contributing.
- When codebase owners and external contributors don’t work together, nothing gets better and everyone ends up discouraged.
Recognizing and rewarding TCs
The TC role illuminates a developer’s advanced skills in mentoring, deep knowledge of architecture, and best code-review practices. Being a TC is a time consuming and important responsibility, therefore these individuals should be recognized and rewarded within their teams and the organization.