Add initial slidedeck and fix some typos

Author: ocaisa

docs/ci.md

@@ -10,8 +10,8 @@
 
 **Continuous Integration (CI)** is a software development practice where developers frequently merge their code changes
 into a shared repository. Each time code is added or updated, automated processes build the application and run tests
-to verify that everything still works correctly. This verification workflow is exactly the process we went through in
-the last episode:
+to verify that everything still works correctly. A basic verification workflow is exactly the process we went
+through in the last episode:
 
 * Prepare the environment
 * Build the application
@@ -58,7 +58,7 @@ and GitLab to make sure this is the case:
 
     The [EESSI GitLab Component](https://gitlab.com/explore/catalog/eessi/gitlab-eessi) also exists, and this allows
     you to follow a very similar approach to that described
-    here for GitHub. At the end of the episode we will provide the equivalent file needed to enable GitLab CI.
+    here for GitHub. Near the end of the episode we will provide the equivalent file needed to enable GitLab CI.
 
 The first thing we need to do is to translate our workflow into something that the workflow tool, GitHub Actions in
 this case, can understand. GitHub itself has
@@ -199,7 +199,7 @@ To github.com:vlad/cicd-demo.git
  * [new branch]      add_ci_to_project -> add_ci_to_project
 ...
 ```
-(where `vlad` is replaced by your own GitHub user handle). Let's go ahead and create the pull request lile the text
+(where `vlad` is replaced by your own GitHub user handle). Let's go ahead and create the pull request like the text
 suggested by visiting the URL. Once we open the link, we can modify the title/description if we wish, but otherwise
 we can just go ahead and click "Create pull request".
 
@@ -287,8 +287,8 @@ will become a green tick which indicates that our CI for the commit has passed.
 
 ### What happens when CI fails?
 
-What does a failure look like in CI? From the previous episode, we know that if we do not load the `buildenv` module
-our tests should fail. Let's
+What does a real failure look like in CI? From the previous episode, we know that if we do not load the `buildenv`
+module our tests should fail. Let's
 construct that scenario, by commenting out the line that loads that module:
 ```yaml title="ci.yml"
 --8<-- "scripts/ci-broken.yml"
@@ -301,7 +301,7 @@ git commit -m "Don't load buildenv, which should break our CI"
 git push origin add_ci_to_project
 ```
 
-Eventually, as expected, our CI will fail and we will get a red X beside our commit. We should also receive an email
+Eventually, as expected, our CI will fail and we will get a red `X` beside our commit. We should also receive an email
 notification that our CI has failed. Such notifications are a critical part of CI, the value of CI is not just that
 the tests run silently, but that we are made aware immediately when things go wrong.
 

docs/downloads/EESSI_tutorial_slides_ISC2026.pdf

@@ -14,6 +14,11 @@ EESSI provides a shared, portable, and optimized software stack for scientific c
 
 For those attending the live tutorial at ISC 2026, there is a [prepared environment](prepared-environment.md) available.
 
+!!! note "Slidedeck for the ISC 2026 tutorial"
+
+    The slidedeck for the tutorial given at ISC 2026 is available:
+    <a href="downloads/EESSI_tutorial_slides_ISC2026.pdf" download="EESSI_tutorial_slides_ISC2026.pdf">Download PDF</a>
+
 1. [Introduction to EESSI](introduction.md)
 2. [Getting Access to EESSI](getting-access.md)
 3. [Using EESSI](usage.md)

docs/index.md

@@ -10,7 +10,7 @@
 EESSI is sometimes described as "container without a container runtime". What that means is that it effectively
 provides an alternative operating system to the native one without the need for something to negotiate between the two.
 When we are _consuming_ software from EESSI, there is no real way to see this. It is only when we try to use EESSI as a
-basis for building new sotware that we are exposed to the additional complexity that this can bring.
+basis for building new software that we are exposed to the additional complexity that this can bring.
 
 ## Building a software project
 
@@ -149,8 +149,8 @@ $ module spider hdf5
 We can see there are multiple versions available, but which one do we choose? Our application doesn't specify a specific
 version so we just choose the latest, `HDF5/1.14.6-gompi-2025b`, for now.The actual version of HDF5 is given by the
 first part of `1.14.6-gompi-2025b`, in this case `1.14.6`; the final part `gompi-2025b` is related to the
-[toolchain concept inside EasyBuild](https://docs.easybuild.io/common-toolchains/) and we won't get into that here
-since it is not the purpose of the tutorial.
+[toolchain concept used by EasyBuild](https://docs.easybuild.io/common-toolchains/). We won't dive into that toolchain
+concept here since it is not the purpose of the tutorial.
 
 Having chose to try out `HDF5/1.14.6-gompi-2025b`, we can now load the module to make HDF5 available:
 ``` { .bash .copy}