markdown source builds

Auto-generated via `{sandpaper}`
Source  : 5ac731f
Branch  : main
Author  : Matthew <6177028+bielsnohr@users.noreply.github.com>
Time    : 2025-05-30 16:18:18 +0000
Message : Merge pull request #462 from hsaunders1904/458_fix_discrepancy_in_git_instructions

Correct links and a typo in slides of section 3/4

Author: actions-user

common-issues.md

@@ -143,7 +143,7 @@ Git Bash uses its own SSH library by default, which may result in errors such as
 even after adding your SSH key correctly:
 
 ```
-$ git clone git@github.com:ukaea-rse-training/python-intermediate-inflammation
+$ git clone git@github.com:carpentries-incubator/python-intermediate-inflammation.git
 Cloning into 'python-intermediate-inflammation'...
 git@github.com: Permission denied (publickey).
 fatal: Could not read from remote repository.

md5sum.txt

@@ -39,7 +39,7 @@
 "instructors/instructor-notes.md" "0145a4d0e4df14ce1d4f08ecaa171515" "site/built/instructor-notes.md" "2024-12-06"
 "learners/quiz.md" "bd60170ec9f07bc2d510f55353179217" "site/built/quiz.md" "2024-12-06"
 "learners/installation-instructions.md" "516ae49d52941813dae9d2ed82bd6127" "site/built/installation-instructions.md" "2024-12-06"
-"learners/common-issues.md" "8365733ad45b543bae6a4e523b6f88aa" "site/built/common-issues.md" "2025-04-01"
+"learners/common-issues.md" "4661f811bdea175eda7b77ae2a7cc605" "site/built/common-issues.md" "2025-05-30"
 "learners/software-architecture-extra.md" "75cca9330b84bddf8223944131639f4f" "site/built/software-architecture-extra.md" "2024-12-06"
 "learners/programming-paradigms.md" "2c3cdee71c1c975c0cf99260493b6e67" "site/built/programming-paradigms.md" "2024-12-06"
 "learners/procedural-programming.md" "ede81ccae989c46e47af0417ac31b401" "site/built/procedural-programming.md" "2024-12-06"
@@ -54,5 +54,5 @@
 "slides/section_1_setting_up_environment.md" "65631efd5db06ee9335f3ef026bdab72" "site/built/section_1_setting_up_environment.md" "2025-05-27"
 "slides/section_2_ensuring_correctness.md" "9ff6a044969f7959e32ffd1d9c60edd8" "site/built/section_2_ensuring_correctness.md" "2025-05-27"
 "slides/section_3_software_dev_process.md" "2f273ac5d34158dfc0cd0e98c8308c82" "site/built/section_3_software_dev_process.md" "2025-05-27"
-"slides/section_4_collaborative_soft_dev.md" "1a525b52fc0b08d2abd669411df544d5" "site/built/section_4_collaborative_soft_dev.md" "2025-05-27"
+"slides/section_4_collaborative_soft_dev.md" "e99956f241d3fe9c9c38f37c2cb40ff6" "site/built/section_4_collaborative_soft_dev.md" "2025-05-30"
 "slides/section_5_managing_software.md" "378f9bc03723cc1113cc4766df35186d" "site/built/section_5_managing_software.md" "2025-05-27"

section_4_collaborative_soft_dev.md

@@ -23,7 +23,7 @@ jupyter:
 - up until this point, the course has been primarily focussed on technical practices, tools, and infrastructure, and primarily from the perspective of a single developer/researcher, albeit within a team environment
 - in this section, we are going to start broadening our attention to the collaborative side of software development
   - there are primarily two practices that facilitate collaboration: code review and package release
-- code review has many benefits, but top among them is that it provides a gate check on software quality, 
+- code review has many benefits, but top among them is that it provides a gate check on software quality,
   - it is also a way to share knowledge within a team, improving the redundancy of that team (which is actually a good thing regardless of what corporate types might say!)
   - getting another set of eyes on your code also means you are less likely to flout coding standards and convention
   - there are many different types of code review, and we will explore the most common in this section
@@ -46,7 +46,7 @@ git branch --all
 If not, please run these commands:
 
 ```bash
-git remote add upstream git@github.com:ukaea-rse-training/python-intermediate-inflammation.git
+git remote add upstream git@github.com:carpentries-incubator/python-intermediate-inflammation.git
 git fetch upstream
 git checkout upstream/feature-std-dev
 git switch --create feature-std-dev
@@ -204,20 +204,20 @@ Follow the instructions under this exercise heading. Read the content above the
 <!-- #endregion -->
 
 <!-- #region slideshow={"slide_type": "subslide"} -->
-- 🔁 We want our code to be somewhere on the "reusablility" spectrum
+- 🔁 We want our code to be somewhere on the "reusability" spectrum
 - 📝 Documentation is an important part of our code being reusable
 <!-- #endregion -->
 
 <!-- #region slideshow={"slide_type": "notes"} -->
-- We want our code to be somewhere on the "reusablility" spectrum
+- We want our code to be somewhere on the "reusability" spectrum
   - but where exactly? this will depend on the maturity of your code and how widely it will be used (similar to testing)
   - at a minimum, we want to aim for reproducibility if we are publishing: someone else should be able to take our code and data and run it themselves and get the same result
   - however, for big library packages, we probably want to bump that up to reusable, where our code is easy to use, understand, and modify
 - Documentation is an important part of our code being reusable
   - Even if you write incredibly expressive code, it will not be enough for someone new to start using and modifying your code base
   - How do they install it? Are there any development tools they need? What is the scientific context and limitations of the code?
   - We need to answer all of these questions and more if we want our code to be approachable and reusable
-  
+
 TODO would be nice to modify the image from <https://the-turing-way.netlify.app/_images/reproducible-definition-grid.svg> so that it better reflects the ACM definition of reproducibility/replicability
 <!-- #endregion -->