Skip to content

Latest commit

 

History

History
96 lines (72 loc) · 4.47 KB

02-becoming-a-contributor-script.asciidoc

File metadata and controls

96 lines (72 loc) · 4.47 KB

#Script: The Contributor in InnerSource - Becoming an InnerSource Contributor

Duration: 3-5 Mintes

Actors: Isabel and Johannes

Playbook Summary

How do some people seem to find opportunity to contribute to projects everywhere? This segment describes the mindset and habits that create opportunities to become an InnerSource Contributor.

Script

I: Welcome back to our video series on the contributor role in InnerSource. In this episode you are going to learn more on what it takes to become a successful contributor in the InnerSource project of your choice. We’ll be checking out what a sharing mindset has to do with contributing, what the benefits of sharing solutions are and which types of contributions InnerSource projects are typically looking for.

-> Show gaining by sharing slide.

J: Imagine you are implementing a new feature for your product. Before jumping right into the implementation - slow down for a bit: Is this a general issue that could benefit from a solution that multiple teams work on? Do other teams face the same challenge because they operate in the same business domain? Is this functionality orthogonal to your business domain?

J: If any of this is the case - look beyond your own team: Is there a shared solution that you can rely on? Should there be one?

-> Show dealing with dependencies slide 1

I: So you’ve found that the functionality that you need already exists within your company. On a technical level, the solution is easy: Introduce a dependency in your project, go ahead and re-use what others did before.

-> -> Show dealing with dependencies slide 2

What looks easy on first sight becomes more complicated when we remember that all of those components are being built by humans - colleagues, working in different teams, potentially against different roadmaps, potentially using different design patterns than your own team. Introducing dependencies light-heartedly comes at a cost: The features you need, may not be on the roadmap of the team working on that component. The component may lack some minor modification that you need in order to meaningfully use it. At the end of the day you make your success dependent on another team.

-> -> Show dealing with dependencies slide 3

J: The typical solution is to cut dependencies whereever possible. This means that you can move independent and faster. It also means that you will duplicate effort that others already invested.

-> -> Show dealing with dependencies slide 4

InnerSource gives you a path in between the two options of being fully dependent on another team or cutting the dependency entirely:

For InnerSource projects you are invited to join the effort. If a feature you need is not provided and is not on the roadmap of the original team just yet, you have the option to implement that feature yourself and contribute that implementation to the project. Instead of spending all the effort to re-implement the entire functionality you can focus on only adding the feature that you need. In addition you will get help and mentorship on how to make the modifications that you need.

I: Contributing those changes to the other team’s codebase means that they will take over maintanance for you going forward reducing the work that you will have to do.

As a good contributor you should be able to make a call for when re-using a component provides a benefit to your team in terms of collaboration with others to move faster and reduce waste.

-> -> Show more than source code slide

J: So - it’s called InnerSource - that means, this is just about source-code, correct?

If you are a user of an InnerSource project, you want to ensure the project is well run and well maintained. You can help the host team with that: In addition to source code contributions, you can help with improving the documentation. You can help with providing issues for bugs you find. You can help by providing additional information to existing issues. You can help with fixing tests. In addition to reporting bugs you can help with providing (failing) test cases for these bugs. You can help with mentoring other users of the InnerSource component.

I: With that we would like to conclude this section on becoming a contributor. In this episode we looked into when you should look into becoming an InnerSource contributor, what benefits are waiting for you. FIX We also touched upon types of contributions beyond source code. In the following video section you will learn more about the contributor ethos - on what being a good contributor looks like.