Finished fixing up Communication Risk

docs/practices/Communication-And-Collaboration/Documentation.md

@@ -13,8 +13,6 @@ practice:
    - "Guides"
    - "Technical Writing"
   mitigates:
-   - tag: Invisibility Risk
-     reason: "Makes all aspects of the project transparent and accessible to the team."
    - tag: Communication Risk
      reason: "Provides clear guidelines and information, reducing misunderstandings."
    - tag: Internal Model Risk

docs/practices/Deployment-And-Operations/Automation.md

@@ -26,7 +26,7 @@ practice:
      reason: "Introducing automation adds to the complexity of a project"
    - tag: Feature Fit Risk
      reason: "The automated process might not capture the variability of requirements of the original approach"
-   - tag: Invisibility Risk
+   - tag: Communication Risk
      reason: "The quality and performance characteristics may be obscured by automation."
    - tag: Process Risk
      reason: "Automation introduces a process, which therefore means a new source of Process Risk."

docs/practices/Development-And-Coding/Version-Control.md

@@ -20,7 +20,7 @@ practice:
    - tag: Regression Risk
      reason: "Maintains a history of changes, allowing rollback to previous versions if needed."
   attendant:
-   - tag: Invisibility Risk
+   - tag: Communication Risk
      reason: "Poor version management can be chaotic and leave lots of work in progress."
   related:
    - ../Planning-and-Management/Change-Management

docs/risks/Communication-Risks/On-Channels.md

@@ -22,17 +22,17 @@ The channel characteristics also imply suitability for certain _kinds_ of messag
 
 Shannon discusses that no channel is perfect:  there is always the **risk of noise** corrupting the signal.  A key outcome from Shannon's paper is that there is a tradeoff:  within the capacity of the channel (the **bandwidth**), you can either send lots of information with _higher_ risk that it is wrong, or less information with _lower_ risk of errors.
 
-But channel risk goes wider than just this mathematical example:  messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive.  Sometimes, a channel is just an inappropriate way of communicating.  When you work in a different time-zone to someone else on your team, there is _automatic_ [Channel Risk](/tags/Channel-Risk), because instantaneous communication is only available for a few hours a day. 
+There are practical implications to this:  messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive.  Sometimes, a channel is just an inappropriate way of communicating.  When you work in a different time-zone to someone else on your team, there is _automatic_ [Communication Risk](/tags/Communication-Risk), because instantaneous communication is only available for a few hours a day. 
 
 When channels are **poor-quality**, less communication occurs.  People will try to communicate just the most important information.  But, it's often impossible to know a-priori what constitutes "important".   This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Channel Risk](/tags/Channel-Risk) by ensuring high-quality communication channels are in place.
 
 At other times channels are crowded and can contain so much information that we can't hope to receive all the messages.  In these cases we don't even observe the whole channel, just parts of it. 
 
 ### Marketing Communications
 
-When we are talking about a product or a brand, mitigating [Channel Risk](/tags/Channel-Risk) is the domain of [Marketing Communications](https://en.wikipedia.org/wiki/Marketing_communications).  <!-- tweet-end --> How do you ensure that the information about your (useful) project makes it to the right people?  How do you address the right channels? 
+When we are talking about a product or a brand, mitigating [Communication Risk](/tags/Communication-Risk) is the domain of [Marketing Communications](https://en.wikipedia.org/wiki/Marketing_communications).  <!-- tweet-end --> How do you ensure that the information about your (useful) project makes it to the right people?  How do you address the right channels? 
 
-This works both ways.  Let's looks at some of the **Channel Risks** from the point of view of a hypothetical software tool, **D**, which my team would find really useful: 
+This works both ways.  Let's looks at some of the **Communication Risks** from the point of view of a hypothetical software tool, **D**, which my team would find really useful: 
 
  - The concept that there is such a thing as **D** which solves my problem isn't something I'd even considered.
  - I'd like to use something like **D**, but how do I find it?

docs/risks/Communication-Risks/On-Messages.md

@@ -43,9 +43,9 @@ For people, nothing exists unless we have a name for it. The world is just atoms
 
 People don't rely on rigorous definitions of abstractions like computers do; we make do with fuzzy definitions of concepts and ideas.  We rely on [Abstraction](/tags/Abstraction) to move between the name of a thing and the _idea of a thing_.
 
-This brings about [Misinterpretation](/risks/Message-Risk#misinterpretation): names are not _precise_, and concepts mean different things to different people.  We can't be sure that other people have the same meaning for a name that we have.  
+This brings about [Misinterpretation](#2-misinterpretation): names are not _precise_, and concepts mean different things to different people.  We can't be sure that other people have the same meaning for a name that we have.  
 
-Another cost of [Abstraction](/tags/Abstraction) is [Invisibility Risk](/tags/Invisibility-Risk).  While abstraction is a massively powerful technique, it lets the function of a thing hide behind the layers of abstraction and become invisible.  
+So one cost of [Abstraction](/tags/Abstraction) is [Communication Risk](/tags/Communication-Risk).  While abstraction is a massively powerful technique, it lets the function of a thing hide behind the layers of abstraction and become invisible.  
 
 As we saw above, [Protocols](/risks/On-Protocols) allow things like the Internet to happen - this is amazing! But the higher level protocols _hide_ the details of the lower ones.   HTTP _didn't know anything about_ IP packets, for example.  
 

docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md

@@ -30,7 +30,7 @@ Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look
 
 
 
-s And Invisibility Risk
+## Processes And Communication Risk
 
 Processes tend to work well for the common cases because *practice makes perfect*,  but they are really tested when unusual situations occur.  Expanding processes to deal with edge-cases incurs [Complexity Risk](/tags/Complexity-Risk), so often it's better to try and have clear boundaries of what is "in" and "out" of the process' domain.
 
@@ -82,7 +82,7 @@ Let's look at an example of how that can happen in a step-wise way.
 3. Problems are likely to occur eventually in the `B`/`C` relationship.  Perhaps some members of the `B` team give better service than others, or deal with more variety in requests?   In order to standardise the response from `B` and also to reduce scope-creep in requests from `C`, `B` organises bureaucratically so that there is a controlled process (`P`) by which `A` can be accessed.  Members of teams `B` and `C` now interact via some request mechanism like forms (or another protocol).  
 
   - As shown in the above diagram, because of `P`, `B` can now process requests on a first-come-first-served basis and deal with them all in the same way: the more unusual requests from `C` might not fit the model.  These [Process Risks](/tags/Process-Risk) are now the problem of the form-filler in `C`.   
-  - Since this is [Abstraction](/tags/Abstraction), `C` now has [Invisibility Risk](/tags/Invisibility-Risk) since it can't access team `B` and see how it works.
+  - Since this is [Abstraction](/tags/Abstraction), `C` now has [Communication Risk](/tags/Communication-Risk) since it can't access team `B` and see how it works.
   - Team `B` may also use `P` to introduce other bureaucracy like authorisation and sign-off steps or payment barriers.   All of this increases [Process Risk](/tags/Process-Risk) for team C. 
 
 ![Person D acts as a middleman for customers needing some variant of `A`, transferring Complexity Risk](/img/generated/risks/process/step4.svg)