Review Product People Section

product/01-introduction.md

@@ -1,10 +1,10 @@
 Welcome to the learning path section for product managers.
 
-After watching this segment, you will have a better understanding of how InnerSource speeds up product development.
+After completing this segment, you will have a better understanding of how InnerSource speeds up product development.
 We will also cover how it relates to Agile development best practices.
 
-To achive agility organizations strive for autonomous teams.
-However in a complex, interconnected world some dependencies cannot be avoided.
+To achieve agility, organizations strive for autonomous teams.
+However, in a complex, interconnected world, some dependencies cannot be avoided.
 InnerSource [provides an alternative](https://innersourcecommons.org/learn/learning-path/introduction/02/) to "wait it out", "build workarounds" and "escalate": Teams that need modifications in their dependencies can offer a helping hand.
 InnerSource facilitates cross team collaboration.
 Through its focus on written communication, it is well suited even for remote-first mode.
@@ -18,8 +18,8 @@ We will also look at the additional negotiation possibilities that InnerSource b
 But let us start with a brief example.
 Imagine you are building a lovely new music app. 
 In order to understand how your users are interacting with the app you start collecting some interaction logs. 
-Over time you dig deeper when analysing those, feeding your learnings back into development. 
-Now imagine another team bringing content into your application also has a few needs - they may want to reward content creators based on how many users they reached.
+Over time, you dig deeper when analysing those, feeding your learnings back into development. 
+Now, imagine another team bringing content into your application also has a few needs - they may want to reward content creators based on how many users they reached.
 So them, too they start using your collected logs.
 But they need some additional analysis steps that you hadn't thought of at first.
 They are now faced with a challenge: Build a workaround, or go through your backlog to get their request prioritized.
@@ -30,5 +30,5 @@ But it will still be faster than waiting for you to get around to making the mod
 In an ideal InnerSource organisation you can scale that up even further:
 Remember the last time you had to make cross cutting concern modifications across your entire platform?
 When going the "put it into the backlog of each team" this often feels like it's dragging on forever.
-On the other hand having the option to provide teams that need the modification with a patch that suggests the modification can speed things up substantially.
-Typical complexity of modifications in that approach depends on the maturity of the organisation and the maintainability/ modularity of the code produced.
+On the other hand, it speeds things up substantialy to provide those teams with a patch that implements the modification.
+The complexity of modifications in that approach depends on the maturity of the organisation and the maintainability/modularity of the code produced.

product/02-innersource-and-agile.md

@@ -17,7 +17,7 @@ To be able to implement those often lengthy roadmap discussions are scheduled, s
 In complex situations as much as in large organisations this leads to an increase in time needed to adjust to changing business needs.
 For very popular central components often there are so many requests coming in that one central component team runs out of capacity to implement all of the requested changes.
 
-In traditional organizations there are only two ways of making changes to dependencies:
+In traditional organizations there are only [two ways of making changes to dependencies](https://innersourcecommons.org/learn/learning-path/introduction/02/):
 * Submit a feature request/ bug report and wait for the other team to prioritize that change and implement it.
 * Build a workaround to avoid the bug or locally provide the functionality needed.
 
@@ -31,11 +31,11 @@ InnerSource comes with a set of roles and processes that bring clarity to what o
 * Each InnerSource project has a set of Trusted Committers with clear accountabilities that go beyond simply reviewing code.
 Trusted Committers set the rules for contributions.
 * Contributions happen in a structured way:
-   * Contribution intend is shared early to make sure the contribution fits within the Host projects' vision and scope.
+   * Contribution intent is shared early to make sure the contribution fits within the Host projects' vision and scope.
    * Progess is shared early so the host team has a chance to mentor the contributor and guide them on the path to a desired design and architecture.
    That way frustration due to having to decline a contribution late in the process is avoided.
    * Decisions and vital communication happens asynchronously to be able to work around differing meeting schedules of people in different teams.
-As a result contributing teams gain autonomy to fix upstream artifacts without sacrifycing the quality of the component that is being contributed to.
+As a result contributing teams gain autonomy to fix upstream artifacts without sacrificing the quality of the component that is being contributed to.
 
 As a side effect InnerSource provides teams with best practices that make working in a remote first culture easy.
 
@@ -52,7 +52,7 @@ With teams that are familiar with InnerSource the load to move this type of inno
 InnerSource gives your team the initiative and tooling to fix issues that block shipping features to customers.
 When done right maintenance of core components and services can be shared in a well structured way by a "virtual InnerSource team" that is larger than any specific product team.
 
-In advanced settings those involved understand the value of contributors working on simpler features that may not directly benefit their customers - under the condition that that frees the host team to work on more complex changes that contributors hava a business need for.
+In advanced settings those involved understand the value of contributors working on simpler features that may not directly benefit their customers - under the condition that it frees the host team to work on more complex changes that contributors have a business need for.
 
 
 ## Does InnerSource replace Agile?
@@ -84,7 +84,7 @@ This goal now helps with InnerSource as well: Contributions are much easier if c
 Tests also ensure that the host team remembers to keep the contributed functionality if they are reminded of the reason for it by a failing test.
 
 Remember last time you insisted on your team spending time to follow the goal of "leave code in a better shape than you found it"?
-That mindset helps in the InnerSource model: It makes sure that quality and co-hesion of code remains high even when there are multiple contributions from different sources.
+That mindset helps in the InnerSource model: It makes sure that quality and cohesion of code remains high even when there are multiple contributions from different sources.
 
 
 ## Common misunderstandings when coming from agile teams
@@ -112,7 +112,7 @@ In particular where contributions cross team boundaries.
 
 Tools used in InnerSource can formalize this ask for more than one human to be involved with any change.
 
-Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow alogthe process of software creation.
+Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow along the process of software creation.
 As a result all communication needs to be in a place that everyone interested in the conversation can follow along: written, public, searchable and linkable.
 The goal is not to reduce distractions to others - the goal is to make all project conversations transparent.
 
@@ -132,5 +132,5 @@ Without that information contributors will have a hard time understanding which
 
 All discussions in InnerSource projects are visible to everyone in the company.
 Blaming people for their errors, ridiculing them for their mistakes, talking behind their backs about what they did wrong is a sure fire way to kill that trust and leads to the failure of that InnerSource project.
-This is in particular important for anyone in a leadership or role model position.
+This is particularly important for anyone in a leadership or role model position.
 

product/05-shared-ownership.md

@@ -2,7 +2,7 @@
 
 "If everyone owns it, nobody is accountable."
 Traditional organisations perfer to have a single point of contact in case of issues.
-On the other hand allowing simply everyone to make changes surely will reuslt in a mess that can no longer be maintained.
+On the other hand allowing simply everyone to make changes surely will result in a mess that can no longer be maintained.
 
 Based on that observation each InnerSource project has a dedicated team of Trusted Committers.
 Interest in maintaining an InnerSource project often is motivated by enlightened self interest: A team understanding that they themselves need the InnerSource project to fullfill their customers' needs and understanding that opening the project up for contributions can spread the workload to move the project forward.
@@ -26,7 +26,7 @@ Another aspect that becomes more important as the InnerSource project becomes mo
 This does have impact on general capacity planning and should not happen "under the radar".
 
 On the other hand for contributors it is important that code review is not a last stage quality gate.
-Instead it is a way for continiously guiding contributors through the code development process ideally leading to better results faster.
+Instead it is a way for continuously guiding contributors through the code development process ideally leading to better results faster.
 For that to work out in practice there needs to be time and space for team building - but across traditional team boundaries.
 Having at least a vague understanding of the different cultures in teams makes misunderstandings much less likely and the contribution process much more smooth.
 

product/06-relation-to-open-source.md

@@ -7,7 +7,7 @@ This makes understanding two aspects of Open Source easier for teams through par
 
 Much like in InnerSource, Open Source projects have different governance levels.
 Not all Open Source projects are created equal: While some groups only publish the source code, expecting no interaction, others want downstream users to become active and submit patches.
-Other projects have processes setup to allow for sharing impact on the Open Source project.
+Other projects have processes set up to allow for sharing impact on the Open Source project.
 Understanding these governance levels means that deciding which open source project to use in house will take Open Source governance into consideration as well.
 A downstream user of an InnerSource project will have learnt to correctly evaluate the balance between moving fast but being unable to influence a project vs. moving at a slower pace but being able to influence a project together.
 
@@ -48,7 +48,7 @@ When experienced with InnerSource it becomes clear that publishing entire projec
 
 Instead it is much more natural to adopt an enlightened self interest point of view:
 * Where teams use certain Open Source dependencies in vital parts of their components it is important to ensure being involved upstream - even if the only goal is to understand the future roadmap of the project.
-* Where teams have a need for changes in open source projects they depend on, experience with InnerSource makes the advantages of participating upstream obvious: Clearly it is not only about a "sharing is caring" mindset - but it does have clear economic benefits where contributing teams have a highly reduced maintenance overhead of their changes are integrated upstream.
+* Where teams have a need for changes in open source projects they depend on, experience with InnerSource makes the advantages of participating upstream obvious: Clearly it is not only about a "sharing is caring" mindset - but it does have clear economic benefits where contributing teams have a highly reduced maintenance overhead if their changes are integrated upstream.
 
 Taking another step back even the decision of which Open Source project to adopt and use internally will be influenced by the InnerSource experience of a team:
 * InnerSource trains teams to understand what to look out for in terms of ways of collaborating and communicating - from personal experience they will understand why it's important for project to have clear, archived, searchable communication channels.