Increase all header levels by one.

Author: lenucksi

contributor/01-introduction-article.asciidoc

@@ -1,6 +1,6 @@
-= Introduction
+== Introduction
 
-== The Contributor in InnerSource
+=== The Contributor in InnerSource
 
 Have you ever been blocked in your next coding task because another team didn't have time to add a feature in their system that you depend on?
 Perhaps after a while you even had to do some extra work in your project to work around the missing feature.
@@ -14,15 +14,15 @@ This person may or may not be part or see themselves as part of the community.
 However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community's product to interacting with members of the community and finally starting to contribute.
 Finally, some of them may become https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[Trusted Committers].
 
-== Relationship to other roles
+=== Relationship to other roles
 
 As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[_Trusted Committer_] or https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.md[_Product Owner_] and possibly with other contributors.
 At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.
 
 This section gives you a very short overview of the other two roles, but we'd like to encourage you to read the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[introductory article of the Trusted Committer role], and we recommended you read the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/05-lowering-the-barriers-to-entry.md[Lowering the barriers to entry] article, too, before you delve deeper into the details of the Contributor role in this section.
 You can also watch the videos (https://learning.oreilly.com/videos/the-trusted-committer/9781492047599/9781492047599-video323925[introduction], https://learning.oreilly.com/videos/the-trusted-committer/9781492047599/9781492047599-video323929[lowering the barriers to entry]) instead of reading the articles.
 
-=== Trusted Committer
+==== Trusted Committer
 
 A Trusted Committer will be your host for your stay in the hosting community.
 They are the gatekeepers to the project's code repository, and will move your contribution closer to production once they accepted it.
@@ -31,7 +31,7 @@ It is their role to mentor you on your way to contributing to their community. T
 They also need to care about product quality, sustainability and project evolution from technical as well as general perspective, about reducing the barrier to making contributions for everyone, as well as about caring for their community in general.
 Caring for the community involves keeping it healthy, upleveling it and its participants, and advocating its needs in their organization.
 
-=== Product Owner
+==== Product Owner
 
 The role of the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.md[_Product Owner_] has some similarity with the product owner role of your average project.
 However, there are differences - depending on the size of the project, this role is often filled by the same person that acts as trusted committer.
@@ -44,7 +44,7 @@ Last but not least, someone acting as product owner might have been involved in
 
 If you want to learn in more detail what these other roles are about, and we encourage you to do so, we've prepared separate sections about the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[_Trusted Committer_] and the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.md[_Product Owner_].
 
-== Section overview
+=== Section overview
 
 In the following 5 segments you will learn more in detail about the various aspects introduced here.
 

contributor/01-introduction-script.asciidoc

@@ -1,28 +1,28 @@
 #Script: The Contributor in InnerSource - Introduction
 
-== Duration: 1-3 Mintes
+=== Duration: 1-3 Mintes
 
-== Actors: Isabel and Johannes
+=== Actors: Isabel and Johannes
 
-== Playbook Summary
+=== Playbook Summary
 
 How do I best contribute to an InnerSource project?  This segement shares a summary of what it means to be an InnerSource Contributor.  We'll also give an overview of the upcoming training segements on being a great InnerSource Contributor.
 
-== General notes
+=== General notes
 
 J: I took quite a bit of text from the article, since I think there are nice consise parts there.
 However I do think that there's lots of opportunity to narrow it down, comparing it to the 1 minute text size that the intro of the intro video had.
 Thus, this is a work draft to have something to start with and discuss.
 
-== Script
+=== Script
 
-=== Intro
+==== Intro
 
 I:
 
 J: My name is Johannes Tigges. I am a Principal Engineer at 7Learnings, worked on introducing InnerSource to HERE Technologies and have acted as Contributor and Trusted Commiter in a number of projects within companies and the OpenSource domain.
 
-=== Overview
+==== Overview
 
 [EDITOR NOTE J: I think the article text is nice here - shortening some of it though given the 1-3 minutes timeframe.]
 
@@ -34,7 +34,7 @@ I: With projects that incorporate InnerSource principles, you'll never be blocke
 J: The Contributor role describes a person that makes contributions to the repos of an InnerSource community project.
 This person may or may not be part or see themselves as part of the community although this often changes with continuing involvement with the community.
 
-=== Relationship to other roles
+==== Relationship to other roles
 
 \-> Possibly slide with the other two role names?
 
@@ -56,7 +56,7 @@ J: We would like to encourage you to watch the video introducing the Trusted Com
 
 \-> Possibly hinting to some links popping up with the video links ~ YouTube style or just a short link overlay?
 
-=== Section overview
+==== Section overview
 
 \-> Possbly slide with the segment names, popping up one after another?
 
@@ -77,6 +77,6 @@ J: After we've dealt with the personal, the interaction-focused, and the technic
 
 I: The last segment will recap what we've learned about being an InnerSource contributor.  We'll share how you can continue your learning on InnerSource both with other online videos and involvement with the online InnerSource community.
 
-=== Wish people an enjoyable time
+==== Wish people an enjoyable time
 
 J: We wish you an enjoyable time watching the following videos and hope you can take away new insights that are valuable to you.

contributor/02-becoming-a-contributor-article.asciidoc

@@ -1,12 +1,12 @@
-= Becoming an InnerSource Contributor
+== Becoming an InnerSource Contributor
 
 InnerSource contributors operate outside of regular team boundaries, they are the links crossing organisational silos. As such, they need to be aware of a few common practices that make this work more effective.
 
-== Sharing Mindset
+=== Sharing Mindset
 
 So - you're implementing a new feature for your team's product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organisation face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
 
-== Benefits to sharing solutions
+=== Benefits to sharing solutions
 
 There is an African proverb stating that "`If you want to go fast, go alone. If you want to go far, go together.`" The same is true for software development teams:
 
@@ -26,13 +26,13 @@ This way of working requires a change in mindset for many: instead of waiting fo
 
 A good Contributor can comfortably make a call for when it makes both technical and business sense to introduce a dependency and reuse a component instead of duplicating work. They can talk to management to explain the benefits of InnerSource contributions.
 
-== Scope of InnerSource contributions
+=== Scope of InnerSource contributions
 
 So is Inner__Source__ only about __Source__Code? Of course not. If your team's business depends on an outside component, you want to make sure it's well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn't working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.
 
 To summarize no contribution is too small to contribute. Here is one that I made
 to https://github.com/tensorflow/models/pull/4784[tensorflow/models]. A simple label change in a graph.
 
-== Summary of this article
+=== Summary of this article
 
 In this article you learned about what it takes to become a Contributor. We looked at the sharing mindset. We took a deep dive into the benefits of sharing solutions. Finally we had a look at what the scope for InnerSource contributions typically looks like.

contributor/02-becoming-a-contributor-script.asciidoc

@@ -1,14 +1,14 @@
 #Script: The Contributor in InnerSource - Becoming an InnerSource Contributor
 
-== Duration: 3-5 Mintes
+=== Duration: 3-5 Mintes
 
-== Actors: Isabel and Johannes
+=== Actors: Isabel and Johannes
 
-== Playbook Summary
+=== 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
+=== 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/03-contributor-ethos-article.asciidoc

@@ -1,4 +1,4 @@
-= Contributor Ethos
+== Contributor Ethos
 
 In the last segment we have outlined why you would want to reuse components and
 become active as a Contributor. This artice is sharing best practices on how to
@@ -14,7 +14,7 @@ behave in a certain way:
 
 How do these expectations apply to InnerSource projects?
 
-== Getting in
+=== Getting in
 
 When visiting your neighbors, you will likely not enter their home without
 knocking or ringing the door bell even if the door is open. Likewise in InnerSource
@@ -83,7 +83,7 @@ on your submission. This can
 alleviate the host team's fear of the contributors not being available for
 support with fixing bugs after the time on contribution.
 
-== Anticipate and follow house rules
+=== Anticipate and follow house rules
 
 When visiting your neighbors, they will likely help you around in their
 apartment: they'll show you the way to their living room and where the restroom
@@ -116,7 +116,7 @@ archived and searchable. The benefit here is with others coming after you with
 similar proposals: instead of walking the exact same path again, they can learn
 what was discussed before and start from there.
 
-== Understand they are not the home owner and act accordingly.
+=== Understand they are not the home owner and act accordingly.
 
 Being a Contributor essentially means being somehow closer to the host team than
 someone merely requesting a feature. Still Contributors are not accountable for

contributor/03-contributor-ethos-script.asciidoc

@@ -1,14 +1,14 @@
 #Script: The Contributor in InnerSource - Contributor Ethos
 
-== Duration: 5-6 Mintes
+=== Duration: 5-6 Mintes
 
-== Actors: Isabel and Johannes
+=== Actors: Isabel and Johannes
 
-== Playbook Summary
+=== Playbook Summary
 
 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.
 
-== Script
+=== Script
 
 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

contributor/04-mechanics-of-contributing-article.asciidoc

@@ -1,4 +1,4 @@
-= Mechanics of contributing
+== Mechanics of contributing
 
 Are you ready to start contributing to other teams projects/repos?
 Do you look forward to reducing your blockers not by management escalation but by collaboration?
@@ -13,9 +13,9 @@ This article is separated into the three steps you will likely experience
 If your contribution is larger, you'll possibly go through (some) of these steps repeatedly as you iterate towards your common goal.
 It is very likely that, as you do this, everything will feel more and more natural - maybe you'll even wonder why you were doing anything else before.
 
-== Preparing to work
+=== Preparing to work
 
-=== Lead times
+==== Lead times
 
 One key difference is the turnaround time.
 With every first time contribution you are coming to a new (host) team.
@@ -31,7 +31,7 @@ It's better to add more slack time initially - you'll get a feeling about the tu
 Often, you will notice a reduction in turnaround time per host team after making a few successful contributions to that host team.
 This effect can be observed with Open Source as well, you can read more about it <<buildup-of-trust-through-collaboration,here>>.
 
-=== Expectation management
+==== Expectation management
 
 In your classic teams everyone had an idea of the expected lead times.
 Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are.
@@ -41,7 +41,7 @@ Ideally, you can provide them with a rough estimate when you will likely have ti
 Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media.
 Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.
 
-=== Building trust
+==== Building trust
 
 InnerSource puts huge weight on written communication - in particular when it comes to project decisions.
 Does that imply that in-person communication is forbidden?
@@ -50,7 +50,7 @@ Clearly not: while written communication shines when it comes to archiving and s
 Try to make time to meet with people behind the names. If possible, try to meet them over your favorite beverage or some food.
 When you're able to hear people speak, when you know their idiosyncrasies, remote collaboration will become easier.
 
-=== Avoiding rejection
+==== Avoiding rejection
 
 Do you have a large feature that you want to contribute?
 Excellent!
@@ -67,9 +67,9 @@ Ideally, choose the way where artifacts are public, searchable and perma-linkabl
 
 This type of high-level, early upfront agreement will save time in rework or rejection of your pull request down the road.
 
-== Creating the pull request
+=== Creating the pull request
 
-=== Communication and unblocking yourself
+==== Communication and unblocking yourself
 
 Great, you've made yourself familiar with the host team's approach and they are looking forward to receive your pull request.
 Which gotchas are there waiting for you now?
@@ -99,21 +99,21 @@ As you work, if you find missing (or out-of-date) documentation, do a favor to t
 Project teams are often happy to receive additions, updates or corrections for their existing documentation - you've just found another opportunity to contribute!
 (Or just politely provide them with a feedback on your experience, and what would have helped you.)
 
-=== Crafting the code
+==== Crafting the code
 
 We all have our preferences and opinions on code style, indentation, etc.
 The host team's project has them as well.
 Try to adapt and match those preferences even if it's not what you would normally do, and even if it is not specified in the projects' https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/05-lowering-the-barriers-to-entry.md[_`CONTRIBUTING.md`_].
 If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.
 
-== Submitting the pull request
+=== Submitting the pull request
 
 You've completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you've planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.
 
 Here's what you can do to make reviewing and merging as easy as possible for the the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[_Trusted Committer_] and the host team.
 This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that's the case - great, this is going to come natural to you!
 
-=== Testing and automation
+==== Testing and automation
 
 The basic point here is to enable the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.md[_Trusted Committer_] to validate the contribution without your presence and to ensure easy maintainability.
 Imagine you've built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance).
@@ -129,7 +129,7 @@ To achieve this do the following:
  ** If your pull request keeps breaking tests, and you can't find out why after giving it your best shot: try to highlight those tests in the pull request comment, illustrate your current understanding of the problem and ask for help on it.
 * Don't forget your own project that triggered your contribution in the first place. Create a modified build of the shared project with your changes and try it out in your own project that consumes it.
 
-=== Documentation and reviewability
+==== Documentation and reviewability
 
 You'll want to ensure that your pull request includes any documentation updates that are relevant to your changes.
 Should the documentation live in a different place, make sure you add them there and link to them in your pull request.
@@ -150,9 +150,9 @@ You can still bind them together with an issue that you are referring to.
   *** The host team's responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can't fail safe, you can't innovate, and collaboration becomes very hard.
   *** Try to balance between asking for a review early and providing meaningful changes to review.
 
-== Additional articles
+=== Additional articles
 
 Some of these resources might be hidden behind paywalls.
 Sometimes your employer has a subscription enabling access, otherwise public university libraries often allow access for guests, too.
 
-=== https://doi.org/10.1109/MS.2013.95[Buildup of trust through collaboration]
+==== https://doi.org/10.1109/MS.2013.95[Buildup of trust through collaboration]