Replacing BE with AE phrases

Author: spier

project-leader/01-introduction.asciidoc

@@ -29,7 +29,7 @@ Take.
 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
+dig deeper when analyzing 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
@@ -41,12 +41,12 @@ Make the changes themselves - with your help. Sure, that may be slower
 than if you had made the changes. But it will still be faster than
 waiting for you to get around to making the modifications.
 
-In an ideal InnerSource organisation you can scale that up even further:
+In an ideal InnerSource organization 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 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
+the organization and the maintainability/modularity of the code
 produced.

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

@@ -6,18 +6,18 @@ value and maintain autonomy in a highly interconnected world.
 
 === Autonomous teams in an interconnected world
 
-Organisations try to deliver value to customers quickly. One common
+Organizations try to deliver value to customers quickly. One common
 cause for delays are dependencies in the delivery process. As a result
-organisations prefer cross functional teams covering customer
+organizations prefer cross functional teams covering customer
 communication, design, implementation, testing and operations thus
 eliminating costly handovers. To achieve high performance, teams
 eliminate waste and re-use existing components. From a team perspective
 each reused component adds another dependency outside of the control of
-that team. The negative side of this optimisation is clear: The team
+that team. The negative side of this optimization is clear: The team
 depends on another team if they need changes in the component used. To
 be able to implement those often lengthy roadmap discussions are
 scheduled, sometimes leading to the need to optimize detailed priorities
-globally. In complex situations as much as in large organisations this
+globally. In complex situations as much as in large organizations 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
@@ -123,7 +123,7 @@ collaboration. To avoid frequent disruption, host team members often
 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
+team level takes a lot of pressure off the engineers trying to fulfill
 their own team goals but also helping out contributors. Another
 challenge with pairing is that it allows pairs to move very quickly
 together - often at the expense of writing important information down
@@ -164,10 +164,10 @@ sticky notes on a whiteboard. In InnerSource, issue trackers serve for a
 conversation with the customer, but also for communication between
 members of a team of trusted committers and contributors working on one
 common InnerSource component. Issues in InnerSource become much more
-lengthy and wordy than in your average organisation. They also track the
+lengthy and wordy than in your average organization. They also track the
 implementation history and detailed design decisions for a change.
 
-Code Reviews: In traditional organisations code reviews often serve
+Code Reviews: In traditional organizations code reviews often serve
 auditing purposes.
 
 They are done when development is finished. In InnerSource code changes

project-leader/03-capacity-planning.asciidoc

@@ -75,7 +75,7 @@ simply help with reviews, new Trusted Committers can help with issue
 triage, mentoring new contributors and the like.
 
 When faced with a lot of interest in contributions one additional factor
-to consider when prioritising mentoring help for contributors can be
+to consider when prioritizing mentoring help for contributors can be
 interest of the contributors in a long term relationship with the host
 team. The more time is needed for mentoring, the more likely it should
 be for contributors to stick around longer.

project-leader/05-shared-ownership.asciidoc

@@ -1,7 +1,7 @@
 == Options for Shared Ownership
 
 "If everyone owns it, nobody is accountable." Traditional
-organisations prefer to have a single point of contact in case of
+organizations 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.
 

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

@@ -15,7 +15,7 @@ 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
+InnerSource project will have learned 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.