Let’s start with the responsibility most often associated with the Trusted Committer role: ensuring product quality.
In an InnerSource community, the Trusted Committers own all tech-related decisions, especially those related to product quality. Ownership implies the need to make sure the decisions in place are followed through. This includes communicating and—if necessary—advocating for these decisions, inside and outside of the community. But Trusted Committers don’t necessarily make all the tech-related decisions themselves or do all the work to implement them.
It is the Trusted Committer’s job to communicate and clarify quality standards in their community and to formulate them in a way that is understandable and actionable by their Contributors. This includes written documentation, of course, but the most effective way for Trusted Committers to communicate these quality standards is by example. We think it can be a worthwhile goal for an InnerSource community to try and distinguish itself from traditional software development projects not just in the way they organize development but also in the quality of the software they produce, as well. A high level of software quality is essential for establishing and maintaining the trust in the InnerSource community on part of their users and their management. We all know how one bad release can shatter this trust in an instant.
Trusted Committers also make sure the community has the infrastructure and the tools they need to produce quality software. The peer review, usually performed as part of pull requests (PRs), is most frequently used to ensure quality. While everybody can usually start and participate in pull requests by pointing out necessary improvements, it is usually only the Trusted Committer who can ultimately accept and merge or reject a contribution. This is what we meant earlier when we said "Trusted Committers can push code closer to production." Trusted Committers should also help Contributors during a PR to get their contributions over the finish line.
That said, it is ultimately the contributor’s job to make that happen. The job of a Trusted Committer is not to accept all contributions by default, but to only accept those that meet the defined criteria in terms of quality and scope. And Trusted Committers should avoid rewriting a contributor’s code to make it "fit" as much as possible, even if it means spending more time supporting Contributors in a PR. Trusted Committers take a long-term perspective and understand that this kind of support is an investment in the longevity of the community, and it will increase the community’s development speed in the long run.
Sometimes project requirements or limitations are not known upfront and are instead discovered during development. Trusted Committers are also responsible for making sure these findings are captured and documented for both the Product Owners and the Contributors.
But the Trusted Committer’s purview with respect to quality goes beyond pull requests. Trusted Committers think about quality on a strategic level and ensure the longevity of the software being built. This entails code-oriented responsibilities from ensuring cleanliness of the code to maintaining conceptual integrity of the overall software. It also entails management-oriented tasks such as making sure the community is given sufficient time to refactor their software or move a release date in favor of quality improvements, if needed. The effectiveness of the Trusted Committer is strongly related to code health.
Absent the latter, Trusted Committers will have to spend much of their valuable time validating and documenting workarounds for bugs or a fragile architecture and will not have enough time to spend on onboarding and mentoring Contributors.
In conclusion, ensuring product quality is a key responsibility of Trusted Committers. They set quality standards and lead by example. They participate in pull requests and help Contributors meet quality standards. They also take responsibility for the long-term health of the software.
