Merge pull request #134 from jbampton/fix-spelling

Fix spelling

docs/estimating/Stop-Estimating-Start-Navigating.md

@@ -106,7 +106,7 @@ What does that mean?
 
 The problem is that estimation only addresses a single risk:  runway risk/time resource.  It says nothing about other risks that you might bump into.
 
-Why is all my code in the bin?  I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address _Feature RIsk_ properly, or, it was useful, but people didn't find out about how amazing it was.  Or, it was built to work on top of X, but then X was decomissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature RIsk)?
+Why is all my code in the bin?  I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address _Feature RIsk_ properly, or, it was useful, but people didn't find out about how amazing it was.  Or, it was built to work on top of X, but then X was decommissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature RIsk)?
 
 No estimates says forget about trying to get the numbers right, because you can't.  What's better than that?  Let's try and focus on reducing that 90% of waste by thinking about _risks other than time_.
 

docs/practices/External-Relations/Outsourcing.md

@@ -48,7 +48,7 @@ In the extreme, I've seen situations where the team at one location has decided
 
 When this happens, it's because somehow the team feel that [Coordination Risk](/tags/Coordination-Risk) is more unmanageable than [Schedule Risk](/tags/Schedule-Risk).
 
-There are some mitigations here:  video-chat, moving staff from location-to-location for face-time, frequent [show-and-tell](/tags/Review), or simply modularizing accross geographic boundaries, in respect of [Conway's Law](/tags/Coordination-Risk):
+There are some mitigations here:  video-chat, moving staff from location-to-location for face-time, frequent [show-and-tell](/tags/Review), or simply modularizing across geographic boundaries, in respect of [Conway's Law](/tags/Coordination-Risk):
 
 > "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."  - _[M. Conway](https://en.wikipedia.org/wiki/Conways_law)_
 

docs/presentations/OpenSource/index.md

@@ -116,7 +116,7 @@ hide_table_of_contents: true
             <div class="slide-notes">
                       <p>So, that’s often known as a LAMP stack.  So Linux, Apache, we know.  MySQL is a database - so all your wordpress posts get stored in there.  And PHP, Pearl, Python, they’re open-source programming languages - some of the biggest.  And Wordpress is written in PHP.</p>
 
-      <p>All of this is Open Source… except perhaps for MySQL, which was Open Source, but is now owned by Oracle.  But here’s the thing:  once Oracle (somehow) managed to aquire MySQL, the original open-source MySQL became MariaDB.</p>
+      <p>All of this is Open Source… except perhaps for MySQL, which was Open Source, but is now owned by Oracle.  But here’s the thing:  once Oracle (somehow) managed to acquire MySQL, the original open-source MySQL became MariaDB.</p>
 
 
             </div>
@@ -159,7 +159,7 @@ hide_table_of_contents: true
                 <img src="/img/presentations/OpenSource/images/images.010.jpg" alt="Image of slide number 10" />
             </div>
             <div class="slide-notes">
-                      <p>Ok, so here’s a story from before I was at Deutsche Bank, when I was working with Credit Suisse in their Risk department.  We were building a new risk calculator.  And the process went something like this.  The guy on the left, he’s the Analyst.  He writes a requirements document, explaining exactly how he thinks the calcuator should work.  Then, he goes to the pub.  Often, for several days. </p>
+                      <p>Ok, so here’s a story from before I was at Deutsche Bank, when I was working with Credit Suisse in their Risk department.  We were building a new risk calculator.  And the process went something like this.  The guy on the left, he’s the Analyst.  He writes a requirements document, explaining exactly how he thinks the calculator should work.  Then, he goes to the pub.  Often, for several days. </p>
 
       <p>Next, the developer picks up these requirements, and starts programming. </p>
 

docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk.md

@@ -155,7 +155,7 @@ Building software systems that try to optimise for a hierarchy of goals (like hu
 
 ![Universal Paperclips](/img/generated/risks/agency/paperclips.svg)
 
-Bostrom worries that humanity would be steamrollered accidentally whilst trying to maximise the paperclip goal.  The AI need not be malevolent - it's enough that it just requres the resources that keep us alive!
+Bostrom worries that humanity would be steamrollered accidentally whilst trying to maximise the paperclip goal.  The AI need not be malevolent - it's enough that it just requires the resources that keep us alive!
 
 This problem may be a long way off.  In any case it's not really in our interests to build AI systems that prioritise their own survival.  As humans, we have inherited the survival goal through evolution: an AI wouldn't necessarily have this goal unless we subjected AI development to some kind of evolutionary survival-of-the-fittest process too.
 

docs/risks/Dependency-Risks/Deadline-Risk.md

@@ -18,7 +18,7 @@ part_of: Dependency Risk
 
 Let's examine dependencies on _events_.  
 
-We rely on events occuring all the time in our lives, and event dependencies are simple to express: usually, a _time_ and a _place_.   For example:
+We rely on events occurring all the time in our lives, and event dependencies are simple to express: usually, a _time_ and a _place_.   For example:
 
 - "The bus to work leaves at 7:30am" or 
 - "I can't start shopping until the supermarket opens at 9am".
@@ -31,7 +31,7 @@ Having an event occur in a fixed time and place is [mitigating risk](/tags/Mitig
 
 - By taking the bus, we are mitigating our own [Schedule Risk](/tags/Schedule-Risk):  we're (hopefully) reducing the amount of time we're going to spend on the activity of getting to work.  It's not entirely necessary to even take the bus:  you could walk, or go by another form of transport.  But, effectively, this just swaps one dependency for another:  if you walk, this might well take longer and use more energy, so you're just picking up [Schedule Risk](/tags/Schedule-Risk) in another way.
 - Events are a mitigation for [Coordination Risk](/tags/Coordination-Risk): a bus needn't necessarily _have_ a fixed timetable. It could wait for each passenger until they turned up, and then go.  (A bit like ride-sharing works).  This would be a total disaster from a [Coordination Risk](/tags/Coordination-Risk) perspective, as one person could cause everyone else to be really really late.  
--  If you drive, you have a dependency on your car instead.  So, there is often an _opportunity cost_ with dependencies.  Using the bus might be a cheaper way to travel, so you're picking up less [Fuding Risk](/tags/Funding-Risk) by using it.
+-  If you drive, you have a dependency on your car instead.  So, there is often an _opportunity cost_ with dependencies.  Using the bus might be a cheaper way to travel, so you're picking up less [Funding Risk](/tags/Funding-Risk) by using it.
 
 ## But, Events Lead To Attendant Risk
 

docs/risks/Dependency-Risks/Scarcity-Risks/Scarcity-Risk.md

@@ -19,7 +19,7 @@ part_of: Dependency Risk
 
 While [Reliability Risk](/tags/Reliability-Risk) (which we met in the previous section) considers what happens when a _single dependency_ is unreliable, scarcity is about _quantities_ of a dependency, and specifically, _not having enough_.  <!-- tweet-end -->
 
-In the previous section we talked about the _reliability_ of the bus:  it will either arrive or it wont.  But what if, when it arrives, it's already full of passengers?  There is a _scarcity of seats_:  you don't much care which seat you get on the bus, you just need one.  Let's term this [Scarcity Risk](/tags/Scarcity-Risk), _the risk of not being able to access a dependency in a timely fashion due to its scarcity_.  
+In the previous section we talked about the _reliability_ of the bus:  it will either arrive or it won't.  But what if, when it arrives, it's already full of passengers?  There is a _scarcity of seats_:  you don't much care which seat you get on the bus, you just need one.  Let's term this [Scarcity Risk](/tags/Scarcity-Risk), _the risk of not being able to access a dependency in a timely fashion due to its scarcity_.  
 
 Any resource (such as disk space, oxygen, concert tickets, time or pizza) that you depend on can suffer from _scarcity_,  and here, we're going to look at five particular types, relevant to software.<!-- tweet-end -->
 

docs/risks/Dependency-Risks/Software-Dependency-Risk.md

@@ -286,6 +286,6 @@ Choosing dependencies can be extremely difficult.  As we discussed above, the us
 
 > "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - [Abraham Maslow, _Toward a Psychology of Being_](https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail)
 
-Having chosen a dependency, whether or not you end up in a more favourable position risk-wise is going to depend heavily on the quality of the execution and the skill of the implementor.  With software dependencies we often have to live with the decisions we make for a long time: _choosing_ the software dependency is far easier than _changing it later_.
+Having chosen a dependency, whether or not you end up in a more favourable position risk-wise is going to depend heavily on the quality of the execution and the skill of the implementer.  With software dependencies we often have to live with the decisions we make for a long time: _choosing_ the software dependency is far easier than _changing it later_.
 
 Let's take a closer look at this problem in the section on [Boundary Risk](/tags/Boundary-Risk).  But first, lets looks at [processes](/tags/Process-Risk).

docs/thinking/De-Risking.md

@@ -209,9 +209,9 @@ There is a grey area here, because on the one hand you are [retaining](#retain)
 
 ### General Examples
 
-- **Stop-Loss Trades** are an investment where should the trade start loosing too much money, the trade is closed out, limiting the downside.
+- **Stop-Loss Trades** are an investment where should the trade start losing too much money, the trade is closed out, limiting the downside.
 
-- **Incident Reporting Plans**: often businesses will have a procedure for dealing with irregular behaviour (such as a cyber attack). 
+- **Incident Reporting Plans**: often businesses will have a procedure for dealing with irregular behaviour (such as a cyberattack). 
 
 - **Regulations**: firms such as banks or drug companies operate under heavy regulation, designed to control and limit both the amount of risk they take on and that expose their customers to.
 

src/components/FillTheBucket1/index.js

@@ -44,7 +44,7 @@ const chart1 = (model) => {
 	return {
 		type: 'line',
 		id: '1',
-		optons: {
+		options: {
 			scales: {
 				y: {
 					ticks: {

unused_content/complexity/Hierarchies.md

@@ -244,7 +244,7 @@ Subsumptive hierarchies are difficult for a couple of reasons.  The first being
 As an example of this, let's consider _planets_. The definition of a planet is quite bogus, and has changed over time:
 
 - The Greeks coined _asteres planetai_ to be the class of objects in the sky that moved separately from the rest of the body of stars.   Possibly including moons, comets and asteroids. [1](https://en.wikipedia.org/wiki/Definition_of_planet#Planets_in_antiquity).
-- However, after the [Copernican Revolution](https://en.wikipedia.org/wiki/Definition_of_planet#satellites) made the moon a satellite of earth, the defintion of planets seemed to be _bodies orbiting the sun_, and there were just 9 of them: Mercury, Mars, Earth, Venus, Saturn, Jupiter, Uranus, Neptune and Pluto.
+- However, after the [Copernican Revolution](https://en.wikipedia.org/wiki/Definition_of_planet#satellites) made the moon a satellite of earth, the definition of planets seemed to be _bodies orbiting the sun_, and there were just 9 of them: Mercury, Mars, Earth, Venus, Saturn, Jupiter, Uranus, Neptune and Pluto.
 - In 2005, [The Discovery of Eris](https://en.wikipedia.org/wiki/Definition_of_planet#Pluto), a body _larger_ than Pluto orbiting in a trans-Neptunian orbit meant that [potentially hundreds of objects](https://en.wikipedia.org/wiki/Trans-Neptunian_object#/media/File:TheTransneptunians_73AU.svg) deserved the term planet.
 - In response, Pluto was demoted to being a _dwarf planet_.  In order to do this, the definition of planet was changed to include the clause that it had "cleared its neighbourhood" of most other orbiting bodies.  This excluded Kuiper-Belt objects such as Pluto, but is _still problematic_, as Alan Stern discusses below.