Fix trivial spelling issues (BE => AE)

spier · spier · commit ee8799e6127e · 2023-08-02T22:45:26.000+02:00
diff --git a/contributor/02-becoming-a-contributor-article.asciidoc b/contributor/02-becoming-a-contributor-article.asciidoc
@@ -1,10 +1,10 @@
 == 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.
+InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.
 
 === 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?
+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 organization 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
 
diff --git a/contributor/03-contributor-ethos-article.asciidoc b/contributor/03-contributor-ethos-article.asciidoc
@@ -120,7 +120,7 @@ the software project to which they are contributing.
 As a result, the final call on what the contribution must look like is with the
 host team. It helps to approach the host team with a humble
 mindset, with the assumption that all are collaborating towards the purpose of
-the shared organisation. It helps to be open and transparent - not only about
+the shared organization. It helps to be open and transparent - not only about
 what was implemented and how, but also why the change was needed.
 
 Treat any feedback as a gift: others are trying to improve your solution, saving
diff --git a/contributor/05-benefits-of-contribution-article.asciidoc b/contributor/05-benefits-of-contribution-article.asciidoc
@@ -82,19 +82,19 @@ drain of energy that central dependencies bring to the table? Many open source
 projects are being used by a huge number of players - some of who participate
 in their design and development. Encouraging cross team collaboration in InnerSource
 projects at the corporate level means that you can drive central
-innovation from the edges of your organisation.
+innovation from the edges of your organization.
 
 In general it is well understood that projects with a https://en.wikipedia.org/wiki/Bus_factor[bus
 factor] of one or two people pose a
-risk to the organisation - all the more, when that project turns out to be
+risk to the organization - all the more, when that project turns out to be
 central to the purpose of the business. InnerSource helps not only with making such
 projects transparent, but also provides tools to improve that situation by
 putting focus on mentoring and expanding the contributor base.
 
 While cross team collaboration makes assessing individual contributions hard,
-it also enables learning and knowledge sharing within the organisation. As a
+it also enables learning and knowledge sharing within the organization. As a
 result, the impact of individuals will improve. Best practices and positive
-innovation will spread more easily across the entire organisation. As a side
+innovation will spread more easily across the entire organization. As a side
 effect, improvements to the work environment will more easily spread across the
 organization - helping retain employees.
 
diff --git a/contributor/06-conclusion-article.asciidoc b/contributor/06-conclusion-article.asciidoc
@@ -14,6 +14,6 @@ We hope you've enjoyed watching the videos, and/or and reading the articles, and
 
 If you haven't done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/
 
-We invite you to check out the InnerSource group http://innersourcecommons.org[InnerSource Commons] online - feel free to join the discussion and share your experiences and lessons learnt in your organization.
+We invite you to check out the InnerSource group http://innersourcecommons.org[InnerSource Commons] online - feel free to join the discussion and share your experiences and lessons learned in your organization.
 
 Live long and have prosperous projects!
diff --git a/contributor/index.md b/contributor/index.md
@@ -1,4 +1,4 @@
 ---
 title: Learning Path - Contributor
 ---
-The Contributor section covers what it means to be an InnerSource Contributor, the aspects of behaviour that will make you a successful Contributor, contribution mechanics and the benefits of InnerSource for your team and organization.
+The Contributor section covers what it means to be an InnerSource Contributor, the aspects of behavior that will make you a successful Contributor, contribution mechanics and the benefits of InnerSource for your team and organization.
diff --git a/introduction/07-faq.asciidoc b/introduction/07-faq.asciidoc
@@ -16,7 +16,7 @@ It depends! An InnerSource project that encourages small pull requests and has c
 === Why not just open source?
 By all means do so if the project makes sense! Some projects are specific to your company or are a competitive advantage, so you'll want to keep those as InnerSource. Some need to iterate more quickly than can be done in the open.
 
-If your organisation isn't familiar with running open source projects, InnerSource can help people learn the skills required with a view to open sourcing in the future.
+If your organization isn't familiar with running open source projects, InnerSource can help people learn the skills required with a view to open sourcing in the future.
 
 === Will this slow us down?
 It depends on how far you're going. You'll probably be going a lot further than you think.
@@ -29,14 +29,14 @@ If so then your core team is understaffed. A healthy team is staffed so that the
 You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won't be the case.
 
 === How do we convince management this is a good idea?
-Figure out what they want and get a https://innersourcecommons.org/stories[working example of InnerSource], preferably within your organisation, that shows them getting it. If your organization's OSPO manages InnerSource projects, reach out to them for support.
+Figure out what they want and get a https://innersourcecommons.org/stories[working example of InnerSource], preferably within your organization, that shows them getting it. If your organization's OSPO manages InnerSource projects, reach out to them for support.
 
 === How do we convince engineers this is a good idea?
-InnerSource gives engineers the opportunity to develop their career, both in terms of skills and https://patterns.innersourcecommons.org/p/praise-participants[recognition] within their organisation:
+InnerSource gives engineers the opportunity to develop their career, both in terms of skills and https://patterns.innersourcecommons.org/p/praise-participants[recognition] within their organization:
 
 * Broadens their skillset by contributing to different projects, or even different tech stacks!
-* Scales the value they add to the organisation, by having their software run by more people
-* Opportunity to network and collaborate with others in their organisation that they wouldn't normally
+* Scales the value they add to the organization, by having their software run by more people
+* Opportunity to network and collaborate with others in their organization that they wouldn't normally
 
 Also, many engineers value open source; InnerSource embraces open source practices, and can be a step towards open source for many projects.
 
@@ -56,4 +56,4 @@ You should also set clear contribution guidelines, and be transparent on the dir
 
 
 === How do we get people to make contributions?
-Your team and wider organisation's culture must value collaboration. Focus on the business value - teams are able to unblock themselves where software they use have bugs or are missing required features. Where contributors have no immediate business need, you can https://patterns.innersourcecommons.org/p/gig-marketplace[advertise] you are looking for help.
+Your team and wider organization's culture must value collaboration. Focus on the business value - teams are able to unblock themselves where software they use have bugs or are missing required features. Where contributors have no immediate business need, you can https://patterns.innersourcecommons.org/p/gig-marketplace[advertise] you are looking for help.
diff --git a/project-leader/outline.md b/project-leader/outline.md
@@ -1,8 +1,8 @@
 # Audience
 
-While the content of this segment can be intersting to engineers in order to help their teams better navigate business decisions related to InnerSource the core audience are people in your team and across your organisation that deal with product development. The goal of this segment is to help you understand how InnerSource can help interdependent teams resolve requirements without syncing work to the point where both teams operate in lock-step.
+While the content of this segment can be interesting to engineers in order to help their teams better navigate business decisions related to InnerSource the core audience are people in your team and across your organization that deal with product development. The goal of this segment is to help you understand how InnerSource can help interdependent teams resolve requirements without syncing work to the point where both teams operate in lock-step.
 
-Based learnings and best practices of successful, global Open Source projects this training shows you ways to increase collaboration and reduce waste by consollidating work on the shared technological basis. 
+Based learnings and best practices of successful, global Open Source projects this training shows you ways to increase collaboration and reduce waste by consolidating work on the shared technological basis. 
 
 # Takeaways
 
@@ -24,7 +24,7 @@ InnerSource and Agile
 You want to improve your product and deliver those improvements faster to customers. You want to make stakeholders happy. InnerSource helps your team deliver value and maintain autonomy especially in a highly interconnected world.
 
 - Issues InnerSource solves
-   - avoid lengthy roadmap syncronization discussions: "help with solution" instead of "wait it out" or "build workarounds"
+   - avoid lengthy roadmap synchronization discussions: "help with solution" instead of "wait it out" or "build workarounds"
    - resolve cross dependencies without compromising autonomy, code ownership and quality
    - better support for remote first by higher focus on written communication
 
