Update continuous integration practice (#268)

* Update continuous integration practice

* Incorporate review changes recommendations

* Fix the links and formatting to pass the linter check

* Improve formatting

* Typo

* Improve more formatting

* Fix MD031/blanks-around-fences

Author: stefaniuk

.github/workflows/markdown-check-format.yml

@@ -19,6 +19,6 @@ jobs:
       - run: |
           files=$(git diff --diff-filter=ACMRT --name-only origin/${{ github.event.repository.default_branch }}.. "*.md")
           if [ -n "$files" ]; then
-            image=ghcr.io/igorshubovych/markdownlint-cli:sha256:c902fc97bb4ba50cd073408e664fe00414e6e2064f0c213bafd393ea17f3a0fd # v0.32.1
+            image=ghcr.io/igorshubovych/markdownlint-cli@sha256:c902fc97bb4ba50cd073408e664fe00414e6e2064f0c213bafd393ea17f3a0fd # v0.32.1
             docker run --rm -v $PWD:/workdir $image $files --disable MD013 MD033
           fi

.vscode/extensions.json

@@ -1,6 +1,5 @@
 {
   "recommendations": [
-    "ban.spellright",
     "davidanson.vscode-markdownlint",
     "editorconfig.editorconfig",
     "johnpapa.vscode-peacock",

continuous-improvement.md

@@ -23,6 +23,7 @@ Set out with the intention of having this as a permanent part of how you work, i
 ## Improvement Kata
 
 The [Improvement Kata](https://www.atlassian.com/agile/agile-at-scale/using-improvement-kata-to-support-lean) is a product of the [Toyota Production System](https://global.toyota/en/company/vision-and-philosophy/production-system/) and provides a useful structure for wrapping continuous improvement activities:
+
 1. Understand the direction or challenge — expressed as a [measurable signal](#measurement) e.g. _Increase the number of deployments per month_
 1. Grasp the current condition — e.g. _We deploy once per month_
 1. Define the target destination — e.g. _Able to deploy on demand, up to several times per day_
@@ -31,6 +32,7 @@ The [Improvement Kata](https://www.atlassian.com/agile/agile-at-scale/using-impr
 ## Plan-Do-Check-Act improvement cycles
 
 It is common to describe the iterative continuous improvement process as a cycle, and the most common is called Plan-Do-Check-Act (PDCA). This gives a mental model rather than a process to follow, but this can still be useful when adopting and maintaining continuous improvement. The PDCA cycle is attributed to Demming and Shewhart, and here adapted from [ASQ](https://asq.org/quality-resources/continuous-improvement), has four stages which are performed in a continuous loop:
+
 * **Plan**: Identify an opportunity and plan for change.
 * **Do**: Implement the change on a small scale.
 * **Check**: Use data to analyse the results of the change and determine whether it made a difference.
@@ -46,9 +48,9 @@ Continuous improvement has significant benefits for teams.
 
 Improving processes:
 
-*	Reduces waste, leading to improved efficiency and productivity.
-*	Improves quality and reduce error rates.
-*	Leads to happier people and improved engagement, retention, and recruitment.
+* Reduces waste, leading to improved efficiency and productivity.
+* Improves quality and reduce error rates.
+* Leads to happier people and improved engagement, retention, and recruitment.
 
 It takes continuous effort to maintain and evolve processes in response to challenges and changing circumstances. Without this sustained effort, productivity and quality decline over time.
 
@@ -65,6 +67,7 @@ Some important improvement work consists of implementing or improving reliabilit
 Where things like this are missing or need improvement, it is not tech debt — improving them brings a tangible benefit to service reliability, which users do notice and care about.
 
 The benefits of improving these areas are:
+
 * Service has fewer bugs.
 * Performance is more reliable.
 * Services are more available.
@@ -84,6 +87,7 @@ As discused in [Benefits](#benefits), in high level terms the opportunities for
 The [Lean principles](principles.md) give some useful areas to consider.
 
 Examples include:
+
 * The way stories are analysed or elaborated.
 * The way code is written or reviewed.
 * The tools and techniques for testing.
@@ -93,13 +97,15 @@ Examples include:
 ### 2. Technical debt
 
 Examples include:
+
 * Code which needs to be refactored.
 * Technologies which should be replaced.
 * Areas with insufficient, inefficient or ineffective testing.
 
 ### 3. Reliability and operability
 
 Examples include:
+
 * Automated build and deployment pipelines.
 * Monitoring dashboards.
 * Automated alerts.
@@ -109,22 +115,24 @@ Examples include:
 ## Prioritising
 
 Select items which will have the most impact for the effort required. If you have many potential options, you will want to prioritise them. One option is to score how much each will move the [metrics](#measurement) that matter to you — its _value_. You can then use [Weighted Shortest Job First](https://blackswanfarming.com/wsjf-weighted-shortest-job-first/) prioritisation, selecting items with the highest ratio of
-```
+
+```formula
 (value + urgency) / effort
 ```
+
 Value, urgency and effort are judgements and estimates in arbitrary relative units, and it is common to use a [modified Fibonacci](https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating) scale (1, 2, 3, 5, 8, ...) for each.
 
 ### Prioritising tech debt
 
-There is a lot of mileage in following the [scout's rule](https://www.scout.org/sites/default/files/news_files/Leave%20the%20world%20a%20little%20better%20than%20you%20found%20it.pdf) as [applied to coding by Uncle Bob](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) —
+There is a lot of mileage in the _"try and leave this world a little better than you found it"_ scout's rule as [applied to coding by Uncle Bob](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) —
 
 > always leave the code behind in a better state than you found it
 
 — a practice which Martin Fowler calls [opportunistic refactoring](https://martinfowler.com/bliki/OpportunisticRefactoring.html). Making time for this as part of feature work is a very effective way to make incremental improvements to a codebase over time. Factor in any time needed for refactoring or other tech debt improvement when estimating features.
 
 Of course, sometimes you uncover issues which are just to big to tackle as part of an individual feature. For these more substantial issues, it can be useful to apply a little more structure to help with the difficult job of judging the value of fixing any given bit of technical debt. It is helpful to focus on the impact that each is having by considering aspects such as those listed in [Benefits — Control technical debt](#control-technical-debt), shortened here as _bugs_, _delays_, _uncertainty_ and _unhappiness_. The score for each of those aspects will depend on how heavily that part of the system is worked on. Another important consideration is the business _criticality_ of the affected part of the system. By combining the individual scores for each of those aspects you can derive a measure of the total impact, which conveniently also works as a measure of the value of fixing it, which can be fed into Weighted Shortest Job First prioritisation as above.
 
-```
+```formula
 value = criticality x (bugs + delays + uncertainty + unhappiness)
 ```
 
@@ -157,6 +165,7 @@ Break down larger problems into smaller ones which can be tackled with smaller c
 > **Example**
 >
 > The problem "_We don't communicate enough with the other team working in this area._" could break down into several more specific points, helping drive incremental action:
+>
 > 1. _We don't have visibility of each other's backlogs_
 > 2. _We don't coordinate changes and end up clashing_
 > 3. _We don't have the same code style_
@@ -171,36 +180,41 @@ Other teams find it too difficult to determine relative priorities between featu
 ## Measurement
 
 When seeking to [identify](#identifying-improvement-opportunities) and [prioritise](#prioritising) improvements, it can be helpful to have agreed metrics as a guide. These will be specific to each team, but some good defaults to start with are:
+
 * Deployment frequency
 * Lead time for changes
 * Incident rate
 * Mean time to recover
 * Team happiness
 
 In addition, it is useful to track the proportion of time being spent on various activities so that the balance can be corrected if required:
-  * Features
-  * Bug fixing
-  * Operability
-  * Tech debt
-  * Other improvement work
+
+* Features
+* Bug fixing
+* Operability
+* Tech debt
+* Other improvement work
 
 ## What does this mean for me as a less-technical person?
 
 Good engineering and good ways of working are intrinsically connected. Every team member, regardless of how technical they perceive themselves, has a role to play. Think of how your own area of expertise may contribute to improving the metrics the team has selected. Looking at the examples in [Acting](#acting), the conditions to enable increased number of deployments, or better communication, are created by the team as a whole.
 
 Same as for more technical people, continuous improvement should help you reduce waste and enable more focus on the core activities that deliver value from your role. Start with general concepts that may help you identify more specific areas for improvement:
+
 * Can you observe handoffs between "teams-within-a-team"? How could you help reduce or avoid them?
 * Do you have no understanding of what a part of the team is working on? How could that be made more visible?
 * Do you find yourself spending significant time on activities which seem to have no influence on the value of what the team produces? Why do such activities exist, and how could they be reduced or avoided so that time can be better spent?
 
 ## What does this mean for me as a technical person?
 
 If you are an Engineer or Tester, continuous improvement will help you:
+
 * Reduce waste and spend more time delivering value for users.
 * Implement features and fix bugs more quickly and safely.
 * Spend less time on menial or repetitive work.
 
 You have an important role to play!
+
 * Make sure you understand the user needs well enough to have an informed conversation about the relative priority of the functional work items.
 * Express technical work in terms of the benefits it will deliver so that as a team you can have a meaningful conversation about relative priorities.
 * Play an active role in backlog refinement and planning, ensuring that operability and reliability work is adequately represented.
@@ -210,6 +224,7 @@ You have an important role to play!
 ## Closing remarks
 
 As we have seen, the recipe to start or give a boost to continuous improvement is essentially very simple:
+
 1. Make a start, keeping changes small and iterating.
 2. Bake improvement work into the way you work with regular retrospectives which feed a trickle of improvement work into your activity within each Sprint.
 3. Track metrics over time so you can measure the effect of improvement work.

inclusive-language.md

@@ -38,7 +38,7 @@ git remote set-head origin -a
 
 ## Further reading
 
-* [inclusivenaming.org](https://inclusivenaming.org/word-lists/overview/)
+* [inclusivenaming.org](https://inclusivenaming.org/word-lists/)
 * [Internet Engineering Task Force](https://datatracker.ietf.org/doc/draft-knodel-terminology/)
 * [Python](https://bugs.python.org/issue34605)
 * [GitHub](https://github.com/github/renaming)