The InnerSource Workbook

Chapter 4. Video: InnerSource Contributor

Questions

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

SEGMENT: Becoming an InnerSource Contributor

Question 1. What is a benefit of becoming a contributor to an InnerSource project?

1. You can make sure others have to follow your suggestions to improve the project.

2. The host team will maintain the features you add on behalf of your team.

3. You can shape the solution to better fit your team’s needs.

4. You can help shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, and documentation).

Question 2. What assumption should a contributor make when joining an InnerSource project?

1. I need to make sure to communicate my intent when adding to or changing the project.

2. I need to make sure my code serves the hosting team’s goals.

3. If the hosting team is in a bind to meet its deadlines, I have to spend time to code for it.

4. I should work only on features needed by my team.

SEGMENT: The Contributor Ethos

Question 3. What attitude should you take to make successful contributions to an InnerSource project?

1. My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.

2. As a guest to the project, I am entitled to quick and comprehensive answers to my questions from the host team.

3. As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.

4. My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.

Question 4. Which of the following attitudes helps a contributor build a positive relationship with the community?

1. I help the project by thinking up and posting a code change (such as a fix to a bug I have discovered, or new feature I need) right away. The code review will then shake out any issues.

2. I am confident that my contribution will not be rejected, as this would constitute hostile behaviour towards contributors.

3. I stay engaged and available for the project to support my changes and help drive the project forward.

4. I work only with people I am accustomed to working with, as this makes collaboration more efficient.

SEGMENT: Mechanics of Contributing

Question 5. Which of the following expectations help you plan and execute successful contributions?

1. Contributions to a good InnerSource project take about the same time as contributions to my team’s project.

2. I communicate my intent to contribute to the host team early on and ensure agreement on scope and timing.

3. I plan to refactor code I come across during my work as contributor to match my code style, so that it is homogeneous in style and easy to understand.

4. I narrowly scoped pull requests to make them easier to understand, review, and integrate.

Question 6. Which of the following behaviors characterizes successful contributions?

1. If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.

2. My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the continuous integration and continuous delivery (CD/CI) pipeline for the project.

3. I updated the documentation and tests to align with the code changes I contribute.

4. My contribution matches the project’s style.

SEGMENT: Benefits of Contribution

Question 7. What are the benefits for you personally when contributing to InnerSource projects?

1. You can implement a solution you like without the team’s constraints.

2. You share the development effort with others and thus get functionality you otherwise would have needed to implement and maintain yourself.

3. You are building up your reputation within the company.

4. You can become a better engineer.

Question 8. What are some benefits for your team when you contribute to InnerSource projects?

1. A contribution to another team’s code base typically requires less maintenance from you than a change to your own code base.

2. A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.

3. Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.

4. You can influence and help direct shared projects in support of your usage scenarios.

Question 9. What are the benefits for your company as a whole when you contribute to InnerSource projects?

1. Fewer developers are needed to complete projects on time.

2. Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.

3. Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.

4. Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.

Answers

Question 1. What is a benefit of becoming a contributor to an InnerSource project?

1. You can make sure others have to follow your suggestions to improve the project.

2. The host team will maintain the features you add on behalf of your team.

3. You can shape the solution to better fit your team’s needs.

4. You can help shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, and documentation).

Correct answers: 3 and 4

Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay off in long-term benefits to you and the community.

Why 2 is incorrect: It’s correct that contributing a change back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. That way, the work that you as a contributor have to do to adapt to new versions is reduced significantly. Still, when the host team accepts the change, that doesn’t mean they will be the only people responsible for making sure the change you submitted works as intended. Many InnerSource projects institute a 30-day warranty period as a formal means to define how long contributors are responsible for fixing issues in the modification they submitted. Also, contributors often move closer to the host team as they participate in its projects, and provide their expertise going forward.

Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.

Why 4 is correct: Contributions go beyond just code. There are many aspects that help keep a solution healthy and thus make it successful. Different aspects require different skills, all of them important. If you imagine the code as a machine, think of these areas of contributions as the grease that keeps the machine running smoothly.

Question 2. What assumption should a contributor make when joining an InnerSource project?

1. I need to make sure to communicate my intent when adding to or changing the project.

2. I need to make sure my code serves the hosting team’s goals.

3. If the hosting team is in a bind to meet its deadlines, I have to spend time to code for it.

4. I should work only on features needed by my team.

Correct answer: 1

Why 1 is correct: If your contribution isn’t understood by the host team or the community at large, they may reverse your hard work or make other changes that weaken the value of your contribution. Open and early communication with the community and the hosting team will help you drive successful contributions.

Why 2 is incorrect: You should make sure that your goals do not conflict with those of the hosting team, but beyond that you can still promote your own team’s goals.

Why 3 is incorrect: Your work on another team’s project reflects your own team’s needs, but you are not working for the other team. If the hosting team (or any community participant) is in a bind, you and your management might offer help as a gesture to benefit the whole company. However, it is not your task to make up for the time or staffing shortcomings at the hosting team.

Why 4 is incorrect: Working on features that don’t directly benefit your team, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.

Question 3. What attitude should you take to make successful contributions to an InnerSource project?

1. My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.

2. As a guest to the project, I am entitled to quick and comprehensive answers to my questions from the host team.

3. As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.

4. My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.

Correct answer: 3

Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.

Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders.

Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md), and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.

Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. However, your involvement does not end there. You should, at a minimum, fulfill a 30-day warranty on your changes and their impact. Even better, stay close to the community and help out with additional contributions.

Question 4. Which of the following attitudes helps a contributor build a positive relationship with the community?

1. I help the project by thinking up and posting a code change (such as a fix to a bug I have discovered, or new feature I need) right away. The code review will then shake out any issues.

2. I am confident that my contribution will not be rejected, as this would constitute hostile behaviour towards contributors.

3. I stay engaged and available for the project to support my changes and help drive the project forward.

4. I work only with people I am accustomed to working with, as this makes collaboration more efficient.

Correct answer: 3

Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.

Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.

Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.

Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.

Question 5. Which of the following expectations help you plan and execute successful contributions?

1. Contributions to a good InnerSource project take about the same time as contributions to my team’s project.

2. I communicate my intent to contribute to the host team early on and ensure agreement on scope and timing.

3. I plan to refactor code I come across during my work as contributor to match my code style, so that it is homogeneous in style and easy to understand.

4. I narrowly scoped pull requests to make them easier to understand, review, and integrate.

Correct answer: 2 and 4

Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be as straightforward as it is with your immediate team. Your interests and the host team’s interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan to take additional time. This will alleviate stress and tension and increase your chances of a successful engagement.

Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.

Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and conventions in a project is a big undertaking, so you should instead align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants, outside of your current contribution.

Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to your changes being accepted more quickly.

Question 6. Which of the following behaviors characterizes successful contributions?

1. If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.

2. My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the continuous integration and continuous delivery (CD/CI) pipeline for the project.

3. I updated the documentation and tests to align with the code changes I contribute.

4. My contribution matches the project’s style.

Correct answers: 1, 2, 3, and 4.

Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not explained clearly enough, asking a question to members of the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.

Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, CI/CD is valuable in InnerSource.

Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.

Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.

Question 7. What are the benefits for you personally when contributing to InnerSource projects?

1. You can implement a solution you like without the team’s constraints.

2. You share the development effort with others and thus get functionality you otherwise would have needed to implement and maintain yourself.

3. You are building up your reputation within the company.

4. You can become a better engineer.

Correct answers 2, 3, and 4

Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.

Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.

Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.

Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge, thus helping you to design and build better code.

Question 8. What are some benefits for your team when you contribute to InnerSource projects?

1. A contribution to another team’s code base typically requires less maintenance from you than a change to your own code base.

2. A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.

3. Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.

4. You can influence and help direct shared projects in support of your usage scenarios.

Correct answers 1, 2, and 4

Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and now know it well. This will help to maintain your influence and avoid surprises down the road.

Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.

Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.

Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.

Question 9. What are the benefits for your company as a whole when you contribute to InnerSource projects?

1. Fewer developers are needed to complete projects on time.

2. Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.

3. Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.

4. Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.

Correct answers: 2, 3, and 4

Why 1 is incorrect: InnerSource should be adopted in order to align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should ultimately be higher among both teams and their customers.

Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.

Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.

Why 4 is correct: As projects are shared more widely, the teams using them tend to come into closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.