#Script: The Contributor in InnerSource - Contributor Ethos
A Contributor to an InnerSource project is like a guest in a home. How should a Contributor behave in order to have a pleasant visit and also to receive a return invitation? This segment describes how to be a good Contributor in terms of this guest-in-home analogy.
I: In the previous video section we took a closer look at when to become an InnerSource contributor. We also investigated which types of contributions InnerSource projects typically are looking for. In this video you will learn more about how to be a good contributor following the guest-in-home analogy.
-> Show being a guest slide
J: So you are planning to support an InnerSource project. How do you get started? InnerSource contributors understand that essentially they are guests in the house of the host team. When visiting your neighbors - even if their door is open, you probably won’t enter without knocking on the door first.
The same is true for a lot of InnerSource projects: Inviting contributions from the outside does not imply giving write access to everyone right from the start. Instead you will submit your changes through a pull request or patchset and have them reviewed.
I: Much like in the real world you’ll follow contribution guidelines set by the host project. In turn, those active in the project will mentor you.
J: So - is the process the same for all types of changes? Let’s look at a specific scenario in the real world. Remember that lovely summer party that you went to at your friends' place? Likely before knocking on the door you received an invitation with a set time and date. Likely your friends spent some time planning for there to be enough food available.
I: The same is true if you need major modifications in an InnerSource project: Likely you’ll first submit an issue proposing your changes, discussing architectural options. Most likely you will be encouraged to share your progress early. Like Yonik’s law of patches states:
"A half-baked patch in Jira, with no documentation, no tests and no backwards compatibility is better than no patch at all."
Sharing progress early on makes it easier to guide you towards a great solution, showing you caveats. Sharing this project in a way that is visible for the entire InnerSource project enables everyone involved to help you out. Essentially that means sharing a lot more in writing and visible to others.
J: Does that mean that there’s no space for face to face communication? Of course not: Teams need a certain level of face to face interaction. Don’t be surprised though if Trusted Committers are directing you back to the canonical written, archived, searchable medium.
J: Now, once you’re clear to participate in the InnerSource project - will you be able to carry over the same collaboration practices that you’re used to from your own team? Likely only partially:
-> Show following house rules slide.
I: When visiting your neighbors - they’ll show you around. If you’re staying for longer, they’ll tell you what’s particular about their home. In my case you shouldn’t turn on the dish washer and the electric kettle at the same time - otherwise you’ll blow the fuse.
J: You can expect the same explanations of how things work at InnerSource projects: You’ll find that in their README.md (or alternatively in a document called CONTRIBUTING.md) the project has written down information to get you started. It will list anything that deviates from standard tooling.
I: Typically looking at this documentation saves you a lot of ramp up time as it stops you from trial and error but also from going down the wrong path.
J: The more you contribute to a project, the closer you will feel you belong to that project’s team - maybe at some point you’ll be invited to be part of it as another trusted committer. However as long as you’re approaching the project as a contributor you should understand that you are a guest to the InnerSource project. Ultimately accountability for the project lies with the existing Trusted Committers. As such they are the ones who make a final call on what contributions need to look like. Also they are the ones making the final call on whether or not to accept a contribution.
I: In this section we looked at how to get started submitting your contributions to the host team, which rules to follow and how to learn more about how the host team operates. In the following section we will take a closer look at the actual mechanics of creating and submitting contributions.