Fix spelling mistakes

Author: spier

project-leader/01-introduction.asciidoc

@@ -45,7 +45,7 @@ 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, it speeds things up substantialy to provide
+forever. On the other hand, it speeds things up substantially 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

project-leader/02-innersource-and-agile.asciidoc

@@ -54,7 +54,7 @@ Committers set the rules for contributions.
 structured way:
 ** Contribution intent is shared early to make sure the
 contribution fits within the Host projects' vision and scope.
-** Progess
+** Progress
 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
@@ -120,7 +120,7 @@ contributors and schedule that into their planned work. In addition when
 crossing team boundaries it is often hard to find time slots for pairing
 - in those cases it should be complemented with asynchronous
 collaboration. To avoid frequent disruption, host team members often
-need to intentially plan their day more rigorously in InnerSource
+need to intentionally plan their day more rigorously in InnerSource
 settings. Often it is simplest to set aside certain hours in the day or
 a day a week for mentoring contributions. Making that explicit at the
 team level takes a lot of pressure off the engineers trying to fulfil

project-leader/03-capacity-planning.asciidoc

@@ -59,7 +59,7 @@ teams is to make time for splitting changes into smaller chunks. Make
 sure to communicate the wider context these changes belong to though.
 
 Often making larger changes requires communicating intent and purpose
-early. It can also be benefitial to make sure contributing team and host
+early. It can also be beneficial to make sure contributing team and host
 team have enough time set aside for working on the change together. This
 means that people setting team priorities need to think beyond their own
 team when prioritizing changes. However coordination can still happen

project-leader/04-negotiation.asciidoc

@@ -56,7 +56,7 @@ Bob is just beginning to understand the code base and would have trouble underst
 In addition mentoring him through the process would take Alice a lot of time.
 However Alice has several high priority but easy to implement features on her backlog.
 What if Bob took some of those issue off of her backlog and implemented them - in return Alice has time to work on the change that Bob needs?
-For the sake of transperancy those agreements should be explained to both, the host team and the contributing team.
+For the sake of transparency those agreements should be explained to both, the host team and the contributing team.
 Otherwise they will have a hard time understanding why Bob and Alice are not working on the changes that each of their customers needs.
 
 For another example, imagine a host team that is working on a very popular InnerSource project.

project-leader/05-shared-ownership.asciidoc

@@ -1,17 +1,17 @@
 == Options for Shared Ownership
 
 "If everyone owns it, nobody is accountable." Traditional
-organisations perfer to have a single point of contact in case of
+organisations prefer to have a single point of contact in case of
 issues. 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
+that they themselves need the InnerSource project to fulfill their
 customers' needs and understanding that opening the project up for
 contributions can spread the workload to move the project forward.
-Opening a project up for contibutions though doesn't mean that Trusted
+Opening a project up for contributions though doesn't mean that Trusted
 Committers have to accept all submissions. It is the team of Trusted
 Committers that sets the mission and goals for the project. They are
 then in a position to set direction and decide on change acceptance
@@ -85,7 +85,7 @@ term is taken on by the host team.
 InnerSource on a daily basis". While using pull requests and reviews is
 a crucial component, it is just the baseline for InnerSource projects.
 Just because two projects you depend on use pull requests on a daily
-basis does not mean that their openess to team-external contributions is
+basis does not mean that their openness to team-external contributions is
 the same.
 
 InnerSource comes with different best practices. In order to avoid
@@ -124,7 +124,7 @@ can remove the review bottle neck.
 * In the final stage the team of
 Trusted Committers is also ready to share control over who gets write
 access next as well as project vision and mission. While this will often
-result in the highest level of committment from contributors it also
+result in the highest level of commitment from contributors it also
 requires a high level of coordination crossing team boundaries. It also
 requires the highest level of transparency when making decisions about
 the project.

project-leader/06-relation-to-open-source.asciidoc

@@ -55,7 +55,7 @@ be very uncomfortable in particular for employees not used to that way
 of working. In addition all actions being public means they are also
 available for public scrutiny - no longer can every move be vetted by
 corporate communication experts. Similarly produced artifacts are
-available for public scrutiny wrt. license compliance, security and the
+available for public scrutiny with regard to license compliance, security and the
 like - e.g. for competitors, for potential future new hires, for
 customers.