Learning Path – Trusted Committer

The Trusted Committer section covers what it means to be an InnerSource Trusted Committer, and how to support your contributors.

Introducing the Trusted Committer Role

The Trusted Committer (TC) role is one of the key roles in an InnerSource community. Think of Trusted Committers as the people in a community that you trust with important technical decisions and with mentoring contributors to ultimately get contributions over the finish line. The Trusted Committer role is both demanding and rewarding. It is more than just being an opinionated gatekeeper and is instrumental for the success of any InnerSource community.

Generally speaking, the Trusted Committer role is defined by its responsibilities, rather than by its privileges. On a very high level, Trusted Committers represent the interests of both their InnerSource community and the products the community is building. They are concerned with the health of both the community and the product. So as a Trusted Committer, you’ll have both tech- and community-oriented responsibilities. We’ll explore both of these dimensions in the following sections.

Before we go into the details of what a Trusted Committer actually does, let’s spend some time contrasting the Trusted Committer role with other roles in InnerSource at a high level of abstraction and explain why we think the name is both apt and important. Let’s start with the Contributor role. A Contributor — as the name implies—makes contributions to an InnerSource community. These contributions could be code or non-code artifacts, such as bug reports, feature requests, or documentation.

Contributors may or may not be part of the community. They might be sent by another team to develop a feature the team needs. This is why we sometimes also refer to Contributors as Guests or as part of a Guest Team. The Contributor is responsible for “fitting in” and for conforming to the community’s expectations and processes.

The Trusted Committer is always a member of the InnerSource community, which is also sometimes referred to as the Host Team. In this analogy, the Trusted Committer is responsible for both building the house and setting the house rules to ensure their guests are comfortable and can work together effectively. Compared to contributors, Trusted Committers have earned the responsibility to push code closer to production and are generally allowed to perform tasks that have a higher level of risk associated with them.

The Product Owner (PO) is the third role in InnerSource. Similar to agile processes, the PO is responsible for defining and prioritizing requirements and stories for the community to implement. The PO interacts often with the Trusted Committer, (e.g., in making sure that a requested or contributed feature actually belongs to the product). Especially in smaller, grassroots InnerSource communities, the Trusted Committer usually also acts as a PO. Check out our Product Owner Learning Path segment for more detailed information.

The role of the Trusted Committer is present in every successful InnerSource community but not every community uses that name. Some communities use the term Maintainer, but this term conflicts with other technical roles such as the “Maintainer” role defined by GitHub, for instance. Apache uses the term Committer, too, but they attach fewer and mostly tech-oriented responsibilities to that role. With its additional community-oriented responsibilities, the Trusted Committer role goes beyond that. The “Trusted” in Trusted Committer means this person is trusted and thus empowered by both their management and their community to do their job. By fostering openness and transparency, Trusted Committers build trust in the process and also in the product being built.

Similar to how naming is important in writing software, choosing the right names for roles and doing so consistently ensures that everyone has the same understanding about the roles played in the community.

Now that you have a basic understanding of the role, why using the term Trusted Committer is appropriate, and know how a Trusted Committer might interact with other common roles in a software project, let’s take a quick look at the responsibilities of a Trusted Committer.

Trusted Committers have various responsibilities, including:

• Ensuring product quality
• Keeping the community healthy
• Reducing the barriers to making contributions
• Upleveling the community
• Advocating the community’s needs

We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a Trusted Committer at the end of this article.

Ensuring Product Quality

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.

Keeping the Community Healthy

The introduction pointed out that Trusted Committers have both tech-oriented and community-oriented responsibilities. It is not sufficient to focus on code and code health only. To ensure success in the long run, Trusted Committers should strive to keep the community building the software healthy as well. Because of that, they must strike a good balance between ensuring product quality and growing a healthy community.

What does a healthy community look like? Quite simply, in a healthy community, Contributors tend to stick around, can spend most of their time developing software, and are able to level up their abilities. As a result, a healthy community will be continually growing.

Why do Contributors join and stick around in a community? Some do because they subscribe to the purpose or the mission of the community. It is the Trusted Committer’s job to clearly articulate and promote this purpose. The importance of this is often not recognized, but marketing a community and its products is truly essential.

Another, more obvious reason for people to stick around is that they enjoy working with other members of the community, including the Trusted Committers. A thriving community is one where members treat and communicate with each other with the utmost respect. Contributions are treated like gifts or donations rather than distractions, and excellent (especially first) contributions are lauded. The Trusted Committer’s job in all this is primarily to set an example for others, similar to setting an example for the level of software quality expected. If necessary, the Trusted Committers are the ones who should create and enact a code of conduct for the community. If there are community members whose behavior is detrimental or toxic to the community’s health, it is the Trusted Committer’s responsibility to address this. Trusted Committers should create opportunities for people to get together regularly (in person or virtually), get to know each other personally and to peacefully resolve conflicts as they arise.

People also tend to stick around because working in an InnerSource community is an excellent opportunity to acquire new skills and to grow personally. This is again where the role of the Trusted Committer is really important. Trusted Committers often become mentors for junior developers, and explicitly spend time during pull requests not only pointing out areas for improvement but also explaining in detail why something needs to be improved and how to do it. They supply the theory or experience behind the change and offer suggestions for the best ways to implement it. By doing so, Trusted Committers can increase the speed of learning in their communities far beyond that in traditional software development projects.

We believe that Trusted Committers should prioritize onboarding and mentoring during pull requests over reaching communicated release dates, unless there is a very good reason not to. Good mentoring during pull requests leads to a higher level of trust and engagement by Contributors, which in turn leads to more contributions. We’ll discuss this more in “Upleveling the Community”.

Finally, some people stick around in InnerSource communities because they get to focus on developing software instead of activities considered overhead or waste, especially common in large companies with a strong focus on processes. The Trusted Committer’s job in this context is to ensure that Contributors can actually focus on their projects by communicating and enacting helpful contribution guidelines.

One important aspect of these guidelines is to explain what we call signaling in pull requests: what should a comment look like? What does it mean if I like or +1 a comment? How is @mentioning someone with a /CC prefix different from using a /FYI prefix? Generally speaking, Trusted Committers need to make sure that the contribution process does not create more problems, but instead supports the community in identifying and solving problems. Ultimately, Trusted Committers should empower their community to find process-related problems and to adapt and improve them as a community as much as possible.

For Trusted Committers to be able to fulfill all these responsibilities, it is important that they communicate regularly with community members and keep an ear to the ground. We’ll go into more detail about this in the section in “Advocating the Community’s Needs”.

In summary, Trusted Committers should strive to create a welcoming and appreciative environment for their Contributors that allows them to concentrate on writing software and growing personally by creating opportunities to learn from other community members.

Upleveling Community Members

There is a continuum of participation in an InnerSource community. There are people who are not aware of the community. Newcomers might be interested in the community and its product, but have not yet used it. Consumers use the software but may not have made a contribution. Then there are the Contributors who have made at least one contribution, and finally the Trusted Committers, who are taking responsibility for both the software and the community. As a Trusted Committer, you are responsible for moving individuals along this continuum and upleveling their ability to make contributions. In this sense, Trusted Committers act as force multipliers in their community.

It is important for Trusted Committers to market their product and communities to increase the number of newcomers and consumers. They should also communicate opportunities to make contributions to consumers and try to elicit and align the interests of potential Contributors with that of the community. What often works well is if Contributors are able to work on something that benefits their department or role in the company. Development tools and automation are good examples.

Finally, it is the Trusted Committer’s responsibility to identify and support Contributors with the potential to grow by encouraging them to tackle challenging tasks and mentor them towards completion. This is, in our opinion, a Trusted Committer’s noblest responsibility, and it is rewarding for both Trusted Committer and contributor. We’ve heard Trusted Committers say that mentoring and seeing people level up their abilities more than makes up for the fact that they have less time to actually spend writing software.

As mentioned in the previous section, learning and personal growth are reasons people join and stick around in an InnerSource community. Upleveling their Contributors is one of the most powerful tools Trusted Committers have at their disposal to increase the speed, output and longevity of their communities. It is also one of the key arguments with which to convince management to allow their employees to participate in an InnerSource community, as that will make their employees more valuable to the company overall and help them retain top talent.

In summary, Trusted Committers need to attract new Contributors and level up their ability to make contributions. This activity ultimately levels up the community’s ability to create better software faster. They do so by communicating opportunities to make contributions and by helping and mentoring Contributors enabling them to grow.

Lowering the Barriers to Entry

Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:

• The sheer number of potential Contributors is lower in InnerSource communities.
• Contributors will want to contribute during their work time, which means they are more time constrained.
• Work in InnerSource might not necessarily be part of Contributors’ official performance goals, so time spent working on InnerSource may seem to detract from achieving those goals.

That’s why it’s important for Trusted Committers to make the processes for making contributions and onboarding Contributors as frictionless as possible. There are a number of things that can help:

• Have a good README.md in each code repository. A good README.md explains what’s in the repository and what it can be used for. In addition, it should provide detailed instructions on how to get, build, test, and use the software in the repository, including information about the license.
• Have a good CONTRIBUTING.md that outlines what is expected of the Contributor. It should answer common questions, such as:
  • How do I submit a bug report or feature request?
  • Who and how do I contact if I have questions?
  • What are the conventions for code style, branching or commit messages?
  • What is the definition of “done” for a contribution?
  • What are the process steps that govern contributions?
  • What is expected of me in terms of supporting contributed code after the contribution is accepted?
  • What is the code of conduct and what are the guidelines to how the community operates?

If you have an internal license attached to the software, which in some companies is a prerequisite for sharing software across legal entities, include a copy of that license and an explanation of the rights and obligations in layman’s terms.

In addition to these documentary tasks, similar to Open Source software development it should be easy and straightforward to run and test the software being developed locally by potential Contributors, so they can start implementing and validating their contribution with as little effort as possible.

There are two common models for making contributions: shared repository and fork and join. Both have advantages, and as a Trusted Committer, you want to support both models to accommodate different needs of your potential and current Contributors. Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. It is therefore important for any InnerSource community to have one or more contact persons that are available for answering such questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member “on call”.

It is also important to help potential Contributors determine what contributions are needed. These can be code contributions but also noncode contributions, such as writing documentation, creating artwork, or organizing events. One common way to do this is to tag “newcomer tasks” in the issue tracker used by the community or to implement a marketplace for open tasks Contributors can use.

In summary, it is super important for InnerSource communities in a corporate environment to keep the barriers to contributing as low as possible to allow as many people as possible to contribute. That means providing both access to helpful documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences.

Advocating for the Community’s Needs

InnerSource communities exist in a corporate context and are thus more constrained than Open Source communities. Sometimes the business unit’s interests are at odds with those of the community. Trusted Committers take a long term perspective on their project. They understand that a healthy community is a precondition for healthy code. This is why many InnerSource initiatives were modeled in the Apache Way with its “Community over Code” motto. Business units, on the other hand, are naturally more concerned with the products produced by an InnerSource community. They prefer to see short to medium-term results that help the bottom line.

It is in this potential area of conflict where the Trusted Committer plays a vital role. Trusted Committers build trust with the organization and, building on that trust, act as advocates for the interests of the community and the long term health of the software in the company. They are responsible for communicating technical, as well as community-related, risks to management. At the same time, Trusted Committers need to be strategic and work within the degrees of freedom afforded by their companies.

Trusted Committers also need to make sure that the community and individual contributors get public credit for their work. Public credit is the currency with which contributors are being paid, especially those who contribute voluntarily. It is a good practice to commend valuable contributors publicly and to make sure their managers are aware of their contributions. Neglecting to give credit can be frustrating for individual contributors and detrimental to the health of the community. This can happen in companies not yet accustomed to the InnerSource working model, or when the software being developed by the InnerSource community runs behind the scenes and managers were simply not aware of the community’s contribution. A good Trusted Committer will engage with management and advocate for public credit. Failure to give credit is almost never done in bad faith and is easy to fix.

Another common case calling for the Trusted Committer’s advocacy is when contributors are not given time or permission to contribute. This can happen when the community is working on a product outside of the contributor’s department and thus not relevant for their manager’s goals. In this case, the Trusted Committer should engage in discussion with the contributor’s manager and lobby for an alternative decision.

In summary, there are many situations in which Trusted Committers need to advocate for the interests of individual contributors and for the community as a whole. Trusted Committers understand that the value the community can provide to the organization depends on the health and longevity of the community and ultimately on a trustworthy relationship between both.

Becoming a Trusted Committer

The Trusted Committer role is a demanding but fulfilling role. If this learning path interests you, you might be wondering how to actually become a Trusted Committer and if you are the right person for the job.

InnerSource communities follow the same principles Open Source communities do, one of which is meritocracy. In a meritocracy, power is vested in individuals based on talent, effort, and achievements. This means the power and privileges that come with the Trusted Committer role need to be earned. Transparency, another Open Source value, also plays a vital role in that it makes the talent, effort and achievements visible to the whole community.

The process of officially becoming a Trusted Committer differs from community to community, depends on where you are in your InnerSource journey and might evolve over time. In grassroots communities, the founders often assume the role of the Trusted Committer. As a community grows, or in larger communities, Trusted Committers are usually nominated or voted in from the community contributors. But the Trusted Committer role should be taken on voluntarily as it requires an immense amount of time and dedication to be successful in it.

What are the criteria to apply in nominating contributors for a Trusted Committer role? What does it take to successfully fill the role of a Trusted Committer? First off, potential Trusted Committers need to have demonstrated a deep technical competence during their work in the community. In addition to that, they must have proven their ability to effectively communicate with peers in the community and ideally also with product owners and with management.

In the same vein, they must have shown the willingness and patience to use their skills and spend intentional time upleveling contributors. Finally, fulfilling the Trusted Committer role requires a certain emotional maturity to deal with stressful social situations, which are bound to come up from time to time. Contributors who satisfy these criteria will be good potential Trusted Committers, in our opinion.

The Trusted Committer role might not appear all that attractive to some contributors as it means spending less time coding. Being nominated for the Trusted Committer role might even be perceived by some as a demotion or as negative feedback on their coding skills. But the opposite is true. Being nominated for the Trusted Committer role usually means someone has recognized your valuable contributions and sees in you the potential to grow and lead. The Trusted Committer role will give you more influence over the evolution of the codebase and will ultimately make you a more complete developer. Explaining to contributors how the software works more often than not leads to new insights on part of the Trusted Committer and will help to identify opportunities to improve the software.

Whether you have one or multiple Trusted Committers depends on the size and the risk associated with the software developed by the InnerSource community. The Trusted Committer role is time consuming, and not everyone is willing or able to make that type of commitment. Because of this, some companies use a Trusted Committer rotation system where multiple Trusted Committers share the workload of the Trusted Committer role, and the Trusted Committers who are not on duty can exclusively focus on tech-oriented work. Having more than one Trusted Committer also makes it easier when someone leaves the company or moves on from the role to do something else. In that case, it is important that there are other Trusted Committers in place already, who can take over and ensure continuity in the community.

In summary, the Trusted Committer role has to be earned by making valuable contributions – both technical and social – for the benefit of the community. In a healthy community, you will have fellow Trusted Committers at your side. As a Trusted Committer, you will have less time to code, but by acting as a force multiplier you will ultimately be able to boost your value contribution to the community and accelerate your own growth.

Conclusion

In the previous chapters we have learned about the responsibilities of Trusted Committers. Some of these responsibilities include ensuring product quality, keeping their community healthy, reducing the barriers to making contributions, upleveling the community and advocating for its needs within the organization. We also talked about how to become a Trusted Committer and what it takes to fulfill that role. Working as a Trusted Committer is demanding but will ultimately amplify your value contribution in your company.

We hope we’ve inspired you to set off on a path towards becoming a Trusted Committer. We also hope we’ve helped your organization understand the importance of having capable Trusted Committers for the success of any InnerSource initiative and the level of empowerment that this role requires.

We’d like to invite you to learn more about InnerSource by exploring the other articles and videos in the InnerSource Learning Path. And of course, we’d be thrilled to welcome you in the InnerSource Commons community.

May the source be with you.

Workbook

1. They are the only ones that are trusted to make commits to the project.
2. They are trusted to keep the software and the community that is developing it healthy.
3. It is the role name used by Apache and GitHub.
4. They are trusted by the product owner to commit the most important features.

Why 1 is incorrect: A good InnerSource project has a community of people submitting commits to the project. The trusted nature of the trusted committer goes beyond just raw coding activity.

Why 2 is correct: The role of the trusted committer is broad and encompasses subtle human interactions. After being chosen for their technical and interpersonal skills, the trusted committers employ a wide range of practices to elicit contributions, build the confidence and skills of the contributors, and ensure positive interactions throughout the community. There are no specifications for such work. It involves trust by the community and product owners.

Why 3 is incorrect: Apache and GitHub have different names for roles that encompass some of the responsibilities of the trusted committer, but not the full set. The role name of “trusted committer” is intentionally unique to InnerSource.

Why 4 is incorrect: Product Owners don’t play favorites as to who implements stories for the community.

TIP: More than one answer may be correct in some questions.

1. Ensuring that a contribution reflects end-user needs
2. Ensuring high code quality in their own submissions and those of other contributors
3. Defending the community’s coding and participation standards
4. Documenting these standards

Why 1 is incorrect: A contributor usually decides to join a project in order to ensure that the code meets a perceived end-user need. Thus, it is the contributors (or their managers) who are responsible for determining end-user needs, and the trusted committer assumes that any contribution is done for a good reason.

Why 2 is correct: Whatever benefits InnerSource offers to contributors and their community, it ultimately must produce top-quality applications in order to be viable. That is the ultimate goal of the process.

Why 3 is correct: Code will be buggy and hard to maintain if contributors fail to follow standards in style and quality. The trusted committer ensures that they do.

Why 4 is correct: Potential contributors have the right to view explicit standards before they try to submit contributions. Documentation is key, and trusted committers should either write the documentation or recruit other knowledgeable people to do so.

1. Track release dates and recommend changes to these dates when needed
2. Scheduling the time of other contributors
3. Recruiting outside contributors
4. Recommending promotions for contributors

Why 1 is correct: The trusted committers know best what state the code is in, how robust it is, and how far they have come to meeting user requirements. Thus, they can recognize earlier than anyone else when a release date is unreasonable. It is their responsibility to communicate the need for a shift to management.

Why 2 is incorrect: Contributors from outside the host team are volunteers, and join a project because they have their own motivations for seeing projects get done. Neither the outside contributors or their managers will tolerate being told how to spend their time.

Why 3 is correct: Although InnerSource is often driven by outsiders who bang on the doors of a host team to be let in, the team can also benefit from reaching out and finding outsiders who can help. The trusted committer can explain to potential contributors how they and their teams could benefit by participating.

Why 4 is incorrect: Promotions, like other personnel matters, are still handled by team managers when InnerSource is in place. InnerSource is about building a productive community and educating its members, not formal rewards. A trusted committer may inform a contributor’s manager about the value and expertise shown by the contributor, but recommending rewards remains outside the trusted committer’s role.

1. Models for their own behavior
2. A layer of the management structure for approving code changes
3. Sources of information about how to write successful contributions
4. Expert coders who implement the contributors’ suggestions

Why 1 is correct: Trusted committers should embody all the traits of a good community member, both in their coding skills and in their interactions. Therefore, contributors are likely to emulate the trusted committers’ behavior and hopefully to become trusted committers themselves.

Why 2 is incorrect: InnerSource, done properly, puts responsibility on the contributors for deciding what code needs to change and how to change it. Trusted committers can make sure that the code follows style guidelines and doesn’t break anything else. However, the trusted committer is not part of management. InnerSource reduces the need for managers to direct projects at a detailed level.

Why 3 is correct: A contributor wants to get their code or other contributions into the host team’s code base; the trusted committer is someone who has done that and can explain how.

Why 4 is incorrect: Contributors take responsibility for code in InnerSource. Trusted committers must resist the temptation to tidy up the contributors’ work. Trusted committers can offer advice, but the contributor implements the ideas.

1. Reviewing pull requests.
2. Documenting community standards.
3. Ensuring that community decisions are of high quality.
4. Writing code as part of each contribution.

Why 1 is correct: A pull request gives a contributor his or her personal sandbox to work in; the contributor then offers the results to the host team. The resulting contribution may require several iterations to reach the necessary quality, and getting there requires feedback from trusted committers.

Why 2 is correct: Documentation helps all contributors agree on what to do. It’s useful for contributors to read the documentation before starting their contributions, and for trusted committers to point to this documentation when requesting changes to a contribution.

Why 3 is correct: Communication and interaction takes on a greater importance in InnerSource. Contributors have opinions about what code should do and how to make it work, so the trusted committer helps communities reach decisions that meet all needs.

Why 4 is incorrect: The healthiest projects have many people working independently. If contributors can take full responsibility for their code, they learn more and can make more contributions. As much as possible, trusted committers avoid handling contributions for which other contributors have taken responsibility.

TIP: More than one answer may be correct in some questions.

1. Making participation fun and engaging
2. Telling contributors what to work on next
3. Reining in difficult or disruptive members of the community
4. Making a contributor feel good just for making a submission

Why 1 is correct: A positive atmosphere brings in more contributions than one that is tense or demeaning. In fact, tense and demeaning projects tend to fall apart. And in any case, a team owes its contributors an uplifting and affirming experience. Trusted committers are the first line of defense against negativity, although management should also create a top-down culture of support.

Why 2 is incorrect: Contributors must have their own motivations to change code. They are not employees of the trusted committer. The trusted committer can suggest that a contributor work on a particular change request or bug, either because the project needs the help or because the task would be a good learning experience, but the contributor makes the final decision.

Why 3 is correct: People may temporarily, or because of their disposition, hurt others psychologically. A single negative interaction can seriously damage a whole community. Trusted committers have learned how to create a positive atmosphere, and they must intervene quickly to halt run-away negative exchanges and explicitly guide others about how to behave.

Why 4 is correct: Some contributors lack the skills to make code of the quality required by a team, or may be constrained by other factors such as time. But InnerSource thrives because of outside contributors, so everyone should be encouraged to try. Encouragement motivates a contributor to listen to advice and try again until the contribution works.

1. A respectful and pleasant community
2. Chances to learn and improve skills
3. More open planning process
4. Quicker implementation of features needed by their teams

Why 1 is correct: Nobody wants to be in an unpleasant group of people. A good community attracts those who can make successful contributions.

Why 2 is correct: Formal training has limited value until the learner tries to apply the skills in real life. A contribution to another project is an excellent way to learn from experience and provide extra dimensions to training.

Why 3 is correct: At least in the conventional view of organizational planning, the knotty questions of feature sets and priorities emerge from high-level managerial meetings. Under InnerSource, a team or even an individual can decide that something needs to get done and then implement it, with guidance from a trusted committer. People end up working on important things because they want to, and the priorities emerge from open, documented discussions.

Why 4 is correct: Instead of waiting for another team to implement a needed feature, contributors can study the code and write up the feature when their own team needs it.This is not done in isolation, but in discussion and collaboration with the host team.

1. Stay out of the contributors’ way.
2. Laud first-time and excellent contributions.
3. Prioritize onboarding and mentorship over milestones.
4. When offering corrections, explain the theory behind the suggested change.

Why 1 is incorrect: Steady facilitation and mentoring from the trusted committer to contributors actually improves community health.

Why 2 is correct: Transparency is one of the virtues of InnerSource. When people contribute, both the community and the organization’s managers should know about it.

Why 3 is correct: Trusted committers think long-term. Although getting each feature done is important, they know that recruitment and training will pay off in years to come with more contributions. Thus, the trusted committer may put in time recruiting or mentoring a contributor for some small contributions, perhaps more time than the individual contribution is worth. Being mentored and treated respectfully increases the likelihood that the contributor will come back for more.

Why 4 is correct: Although review is a key task to preserve the quality of the code base, the trusted committer is thinking long-term during the task. The trusted committer wants the contributor to learn from this experience and apply the lessons to future contributions.

TIP: More than one answer may be correct in some questions.

1. Setting new goals for the community at regular intervals
2. Letting outsiders know about the community and what it offers
3. Encouraging contributors to take on bigger tasks
4. Encouraging members to ignore disruptive comments

Why 1 is incorrect: Goals are set by management. Trusted committers facilitate the work done by others, but do not set the goals.

Why 2 is correct: Many staff fail to appreciate the goals and benefits of InnerSource, particularly when they have not been exposed to its ideas before. Trusted committers are evangelists for InnerSource in general and for their teams in particular. They go so far as to hold special meetings or lunchtime sessions to play up their InnerSource efforts.

Why 3 is correct: We want every person to grow in the job. Contributors usually start small, but are capable of bigger contributions. Trusted committers can encourage them to take on higher-impact work as they go along, and mentor them so that they succeed at that work. The end result is a code base with broader applicability, higher quality, and potentially more features.

Why 4 is incorrect: A disruptive person can be very damaging to the community. Comments that are hostile, demeaning, or even simply distracting should not be tolerated. The trusted committer does not ignore a disruptive comment or tell others to do so. He or she announces to the community that the comment is inappropriate, and then engages in a constructive manner with the disruptive person to ensure no such behavior happens again.

1. It’s not important – the community will do what it needs in order to get its work done.
2. Upleveled community members can begin to help each other, enabling a larger community.
3. A community composed of more mature members will produce better software.
4. Upleveled individuals can augment the host team’s ability to deliver its roadmap.

Why 1 is incorrect: A community does not form spontaneously, even though the need for it is there. A key part of the trusted committer role is supplying the social connection and encouragement for the community and the members in it to work together..

Why 2 is correct: As people gain both skills and confidence, they can offer these skills to others. Contributors can start to act like trusted committers in preserving community standards and educating other members.

Why 3 is correct: One of the crucial purposes of mentoring is to enable each contributor to do better each time, and take on a bigger scope in the project.

Why 4 is correct: As contributors become more sophisticated, their productivity increases and their contributions become more significant. Furthermore, they can help set goals that improve the overall health of the project.

TIP: More than one answer may be correct in some questions.

1. Being too busy with their day job to contribute
2. A lack of consideration for their InnerSource contributions during employee reviews
3. Difficulty building and testing the software in the contributor’s own environment
4. The use of a contributor’s code by other teams

Why 1 is correct: Developers generally have a full plate getting done what their managers assign them. The promise held out by InnerSource is that adding features that your project needs to another team’s project can improve the productivity of your own team, as well as the code of the team to which you are contributing. The open communication fostered by InnerSource also pays off for both teams over time. A contributor may need to persuade their management that the work on another team’s code base will help the contributor’s team and the company achieve its goals faster and more efficiently.

Why 2 is correct: Every effort that benefits a company should be recognized and explicitly rewarded; this encourages employees to take on important new tasks. At the beginning InnerSource is not embedded in a company’s fundamental understanding of its tasks, so managers will not recognize the contributions that their employees make to other projects. Until InnerSource is understood and appreciated by management, employees will find it hard to participate.

Why 3 is correct: Each team may use different tools and repositories. A repository shared across teams makes it much easier to work on the shared code. Related processes, such as handling release builds, bug reports, change requests, and testing, should be designed so people from other teams can work in ways they find familiar. Adding helpful documents such as a CONTRIBUTING.md file explaining the communities’ local customs and describing the way to set up the software in the contributor’s own environment can help to make people from other teams feel at home faster and is much recommended.

Why 4 is incorrect: One of the great benefits of InnerSource is the ability of all teams to use the features designed and coded by other teams. Companies adopt InnerSource largely in order to maximize the value of each code contribution by giving access to the code to every relevant user. .

1. The README file
2. The CONTRIBUTING file
3. Describing the contribution process in step-by-step fashion
4. Answering questions from potential contributors

Why 1 and 2 are correct; Both of these files should be read by contributors before they start participation, and both are good places for team guidelines.

Why 3 is correct: Step-by-step procedures, where they can be defined, help turn the abstract into the concrete. It’s easier to follow a clear procedure than to apply general principles.

Why 4 is correct: The trusted committer offers personal guidance to contributors. It’s useful to preserve such interactions in written form somewhere where other contributors can read and hopefully learn from them.

TIP: More than one answer may be correct in some questions.

1. Make sure that a contributor’s work is directly relevant to his own team’s goals
2. Get recognition for contributors
3. Show potential contributors and their managers why it benefits them to contribute
4. Encourage contributors to take on more responsibility

Why 1 is incorrect: Contributors work on another team’s code in order to meet the needs of the contributor’s team. The contribution should not break anything, of course, so it should not be in direct contradiction to the goals of the trusted committer’s team. But the relevance applies to the contributor’s team, not the trusted committer’s team.

Why 2 is correct: Recognition is both personally satisfying and potentially a step toward formal rewards such as bonuses and promotions. Tools such as version control and bug report databases contain historical records of contributions, but trusted committers should also recognize key contributions in the project’s communication channels.

Why 3 and 4 are correct: Contributors are more likely to invest time and effort when they see that the project benefits them and is appreciated throughout the organization.

TIP: More than one answer may be correct in some questions.

1. Work with a narrow range of contributions
2. Spend more time coding
3. Handle stressful situations on a project
4. Allow the community to scrutinize your behavior

Why 1 is incorrect: Trusted committers tend to expand the scope of their work, not narrow the scope. As a trusted committer, you will work with a variety of people from different teams.

Why 2 is incorrect: Time has to come from somewhere. Trusted committers will have to give up some coding time in order to check other contributors’ code, mentor the contributors, and carry out planning. However, trusted committers should do some coding in order to keep up their own skills and maintain their knowledge of their team’s code base. Some people adopt the trusted committer role for limited periods of time, and return to full-time coding.

Why 3 is correct: A trusted committer takes personal responsibility for the health of the community, and all communities experience stress. Such stress can come from personal disagreements, clashing priorities, constraints on time and resources, or many other sources. The trusted committer must keep calm and deal with these problems.

Why 4 is correct: A trusted committer is not just a technical expert but a role model for behavior. Thus, you should be transparent in your behavior and willing to receive feedback from project participants.

1. Recognizing the value of trusted committers as communicators
2. Restricting each team to just a few trusted committers
3. Keeping the best programmers on coding tasks instead of making them trusted committers
4. Meeting all the deadlines set by management

Why 1 is correct: Many technical projects place great value on technical skills—​which are certainly necessary—​but undervalue what they dismissively call “soft” skills such as communication, problem-solving, and training. InnerSource is a community, and communities require these additional skills. A trusted committer is chosen and recognized for the full range of skills necessary to induce contributions.

Why 2 is incorrect: InnerSource thrives when many people share roles. Healthy teams encourage many qualified developers to become trusted committers. People can also move in and out of the trusted committer role, sharing it with other team members. This improves everyone’s skills.

Why 3 is incorrect: Because trusted committers vet other contributors code and mentor the contributors, managers should want their best developers to become trusted committers at least part of the time.

Why 4 is incorrect: InnerSource focuses on quality code and community-building, not deadlines. InnerSource can sometimes help a team meet its deadlines, because the team can recruit people temporarily from other teams on critical tasks. However, at other times, trusted committers request extensions to deadlines in order to ensure quality.

1. Already made successful contributions to the project.
2. Is on the host team for the project.
3. Actively helps others in the community with questions.
4. Participates in conversations on project roadmap and management.

Why 1 is correct: One of the primary responsibilities of a trusted committer is to help others to contribute successfully to the project. A trusted committer must have a history of doing so themselves in order to be qualified to help others to do the same.

Why 2 is incorrect: This was never cited as a requirement. Although the host team will probably provide trusted committers when the project is first offered to the InnerSource community, it can recruit trusted committers from other teams that care intensely about the project. Regardless of the team that employs the trusted committers, they should arrange the time and resources to participate with their managers, and should act as representatives of the project to the larger community and the organization as a whole.

Why 3 is correct: A large part of a trusted committer’s responsibilities involves social support to contributors. A good candidate will have already exhibited some of this social behavior even before official designation as trusted committer.

Why 4 is correct: The trust placed in a trusted committer extends beyond purely technical considerations. Trusted committers also communicate with the product owner and management. Interest in these areas indicates someone that may be a good trusted committer.

1. Taking on additional responsibility in a project prepares you for expanded leadership in the company.
2. Being in a position of teaching others helps you to understand the project and code better yourself.
3. You can expect an increase in monetary compensation at the time of assuming the responsibilities of Trusted Committer.
4. Your impact on the project expands as you help to shepherd and guide more contributions than you’d have time to write yourself.

Why 1 is correct: Acting as a trusted committer is a great stretch role to build the same leadership skills that will be required if you decide to pursue a full-time leadership role later on.

Why 2 is correct: In all areas, teaching something to others requires that you know it better yourself. This holds true in being a trusted committer. Teaching others will give you added mastery over the project and code you are working on.

Why 3 is incorrect: It is not common that an immediate monetary increase is directly tied to the role of trusted committer. However, the skills required to become a trusted committer and those that are developed by being one tend to be highly valuable to companies. Because of that, becoming a trusted committer tends to be a good career move in building the skills that make you a more valuable leader.

Why 4 is correct: Being a trusted committer is a force multiplier on your impact within the project. As you mentor and uplevel contributors, each of their contributions will carry your mark and influence with them. This effect results in your improving and adding to the project many times faster than you could just by heads-down coding on your own.

1. Company management moves the person that they want to be leading the project into the role.
2. The community or its leadership nominates new trusted committers.
3. Anyone who is interested volunteers.
4. The project founder assumes the role.

Why 1 is incorrect: The principle of meritocracy teaches Trusted Committership is earned, not assigned. It’s also the case that the Trusted Committer should voluntarily accept an invitation to serve rather than being conscripted into the role.

Why 2 is correct: The community is in the best position to evaluate which of its members have demonstrated the interest and aptitudes to serve as Trusted Committer.

Why 3 is incorrect: Interest alone isn’t the only prerequisite for Trusted Committership. The principle of meritocracy teaches Trusted Committership is earned through demonstrated positive activity in the community.

Why 4 is correct: At the outset with no community and no history, the project founder often assumes the role of Trusted Committer to build up an initial community. This person in addition to building up the project also builds up new potential Trusted Committers as they interact with community members.