diff --git a/learners/common-issues.md b/learners/common-issues.md index 09e5f5ace..4212b6fbc 100644 --- a/learners/common-issues.md +++ b/learners/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. diff --git a/slides/section_4_collaborative_soft_dev.md b/slides/section_4_collaborative_soft_dev.md index a4e0a046a..67e9dbbc8 100644 --- a/slides/section_4_collaborative_soft_dev.md +++ b/slides/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,12 +204,12 @@ Follow the instructions under this exercise heading. Read the content above the -- 🔁 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 -- 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 @@ -217,7 +217,7 @@ Follow the instructions under this exercise heading. Read the content above the - 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 so that it better reflects the ACM definition of reproducibility/replicability