Workbook

Workbook

Video: InnerSource Contributor

SEGMENT: Becoming an InnerSource Contributor

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

Question 1. What is a benefit of becoming a contributor to an InnerSource project?
  1. I can make sure others have to follow my suggestions to improve the project.

  2. The host team will maintain the features I add on behalf of my team.

  3. I can shape the solution to better fit my team’s needs.

  4. I can help to shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, 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 longer term benefits to you and the community.

Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. It’s correct that contributing changes 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 being reduced significantly. Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. In practice contributors often move closer to the host team 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 to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.

Question 2. What is a productive assumption for a contributor to make when joining an InnerSource project?
  1. I need to make sure to communicate my intent when adding or changing the project.

  2. I need to make sure my code serves the hosting teams goals.

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

  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, then 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 to 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 other features of a project, 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.

SEGMENT: The Contributor Ethos

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

Question 1. Which approach can drive success in your contribution 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 I am a guest to the project, I am entitled to quick and comprehensive answers to my questions from 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. This helps your status in the community and avoids randomization.

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 plan to be available at a minimum to fulfil a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.

Question 2. Which of the following attitudes helps a contributor build a positive relationship with the community?
  1. The solution owners and reviewers depend on contributions, so I help the project by 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.

SEGMENT: Mechanics of Contributing

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

Question 1. Which of the following expectations help you plan and execute successful contributions?
  1. I understand that contributions to a good InnerSource project take about the same time as contributions to my team’s project.

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

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

  4. I plan my pull requests to be narrowly scoped 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 straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different timezones. To mitigate against these delays, plan with 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 convention in a project is a big undertaking, so you should rather 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 a quicker acceptance of the changes and thus a more immediate benefit to the solution.

Question 2. 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 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 clearly enough explained, asking a question to 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, continuous integration and continuous delivery (CI/CD) are 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.

SEGMENT: Benefits of Contribution

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

Question 1. What are the benefits for you personally when contributing to InnerSource projects?
  1. I can implement a solution I like without the team’s constraints.

  2. I share the development effort with others and thus get functionality I otherwise would have needed to implement and maintain by myself.

  3. I am building my reputation within the company.

  4. I 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 and scope, thus helping you to design and build better code.

Question 2. What are some benefits for your team when contributing to InnerSource projects?
  1. A contribution to another team’s code base requires typically 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 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 3. 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 the 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 be higher at the end among teams as well as 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 in 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.

Contributors