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 that Trusted Committers need to make sure the decisions in place are followed through. This includes communicating and - if necessary - advocating these decisions, inside and outside of the community. 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 motivate 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 this is to set an example for the expected quality standard themselves. 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 software quality is essential for building trust in an InnerSource community on part of their users and their management and we all know how one bad release can shatter this trust in an instant.
The Trusted Committers also make sure that the community has the infrastructure and the tools they need to produce quality software. The tool that Trusted Committers will use most frequently for ensuring quality is the peer review, usually performed as part of pull requests. While everybody can usually start and participate in pull requests by pointing out necessary improvements, it is usually only the Trusted Committers who can ultimately accept and merge or reject a contribution. That is what we meant when we said "Trusted Committers can push code closer to production" earlier. Trusted Committers should also help Contributors during a PR to get their contribution 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 who meet the defined criteria in terms of quality and scope. And Trusted Committers should avoid rewriting contributor’s code to make it “fit” as much as possible, even if it means spend way more time supporting the Contributors in a PR compared to doing it themselves. Trusted Committers take a long term perspective and understand that this kind of support is an investment both in the longevity of the community and the speed at which it will move forward.
Coming back to the project scope: sometimes requirements or limitations for the software being developed are not elicited up front but rather 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.
The Trusted Committers purview with respect to quality goes beyond pull requests, though. Trusted Committers think about quality on a strategic level and ensure the longevity of the software being built. That entails code oriented responsibilities from ensuring cleanliness of the code to maintaining conceptual integrity of the overall software. It also entails more management oriented tasks such as making sure that the community is given sufficient time to refactor their software or move a release date in favor of quality improvements, if the community deems that necessary. The effectiveness of the Trusted Committer is strongly related to code health.
Absent the latter, the Trusted Committer 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 with their contributions to meet the quality standards. They also take responsibility for the long term health of the software.