Fix various typos

episodes/02-better-start-version-control.md

@@ -58,7 +58,7 @@ drwxrwxr-x@   4 mbassan2  staff     128  4 Apr 10:48 astronaut-data-analysis-old
 Over the rest of the course, we will transform a collection of these files into a well-structured software project that 
 follows established good practices in research software engineering.
 
-The first thing you may notice that our software project contains folder `astronout-data-analysis-old` which presumably tries to keep track
+The first thing you may notice that our software project contains folder `astronaut-data-analysis-old` which presumably tries to keep track
 of older versions of the code. There is a better way to do that using version control tool, such as Git, and we can delete 
 this folder so it does not cause confusion:
 
@@ -201,10 +201,10 @@ nothing added to commit but untracked files present (use "git add" to track)
 This tells us that Git has noticed two files in our directory, but unlike Dropbox or OneDrive,
 it does not *automatically* track them. We need to tell Git explicitly which files we want it to track.
 This is not a handicap, but rather helpful, since scientific code can have vast inputs or outputs we might not want 
-Git to track and store (GBs ot TBs of space telescope data) or require sensitive information we cannot share
+Git to track and store (GBs to TBs of space telescope data) or require sensitive information we cannot share
 (for example, medical records).
 
-Before we commit this inital version, we should try to run it. This is often the first thing you might do upon recieving someone's code.
+Before we commit this initial version, we should try to run it. This is often the first thing you might do upon receiving someone's code.
 
 ```bash
 $ python3 my\ code\ v2.py
@@ -219,7 +219,7 @@ Traceback (most recent call last):
 FileNotFoundError: [Errno 2] No such file or directory: '/home/sarah/Projects/astronaut-analysis/data.json'
 ```
 
-We get this error because the paths to the data files have been hard coded as absoulte paths for the original developer's machine.
+We get this error because the paths to the data files have been hard coded as absolute paths for the original developer's machine.
 Hard-coding paths is not very reproducible, as it means the paths need to be changed whenever the code is run on a new computer.
 Instead, we will soon change the code to use the relative paths within the project structure and eventually we will change the code to take in arguments from the command line when it is run.
 When we commit the files, we will note that the code is broken in our commit message.
@@ -287,7 +287,7 @@ Use this additional space to explain why you made changes and/or what their impa
 
 At this point in the lesson, you may choose to demonstrate how the same steps of staging and committing changes can also be achieved with the VS Code graphical interface.
 
-![The Source Control interface to Git in VS Code](fig/vscode-source-control.png){alt="Screenshot of VS Code with the SOURCE CONTROL interface open in the left hand pane of the window. The interface shows one modified file staged for commit, an empty text input box where a commit meesage can be entered, and a green button labeled 'Commit & Push'"}
+![The Source Control interface to Git in VS Code](fig/vscode-source-control.png){alt="Screenshot of VS Code with the SOURCE CONTROL interface open in the left hand pane of the window. The interface shows one modified file staged for commit, an empty text input box where a commit message can be entered, and a green button labeled 'Commit & Push'"}
 
 Depending on your relative levels of comfort working with that graphical interface and the command line interface to Git, you can choose how you want to demonstrate the remaining steps in this episode and when we use Git again elsewhere.
 The lesson will continue to present version control steps with the command line interface only.

episodes/08-open-collaboration.md

@@ -452,7 +452,7 @@ There should be a green "Merge pull request" button, but if we click on the down
 
 The default is option 1, which will keep all of the commits made on our branch intact. 
 This can be useful for seeing the whole history of our work, but if we've done a lot of minor edits or attempts at creating the feature it can be excessive to have all of this history saved. 
-This is where the second option comes in, this will place all of our changes from the branch into just a single commit, this might be much more obvious to other developers who will now see our feautre addition as a single commit in the history. 
+This is where the second option comes in, this will place all of our changes from the branch into just a single commit, this might be much more obvious to other developers who will now see our feature addition as a single commit in the history. 
 The third option merges the branch histories together in a different way that doesn't make merges as obvious, this can make the history easier to read but effectively rewrites the commit history and will change the commit hash IDs. 
 Some projects that you contribute to might have their own rules about what kind of merge they will prefer. 
 For the purposes of this exercise we'll stick with the default merge commit. 

learners/ethical-environmental-considerations.md

@@ -60,7 +60,7 @@ discuss as a group and write down what ethical issues should you consider and ho
    and used by third parties. It's ethical to inform users and seek consent where possible, or at least be transparent
    about data usage.
 4. Impact on website performance - scraping can put significant strain on the forum’s servers, cause Denial of Service
-   attacks amd potentially disrupting service for regular users. Ensure your software is designed to be non-disruptive.
+   attacks and potentially disrupting service for regular users. Ensure your software is designed to be non-disruptive.
 5. Data use and sharing - clearly define and limit the purpose of data collection, collect only the data necessary for
    the intended purpose, and be cautious about how the scraped data is shared or sold. Ensure that it is used responsibly
    and does not harm the users from whom the data was collected.
@@ -98,7 +98,7 @@ reuse.
 ::: solution 
 
 When incorporating other researchers' software into our research workflows we should not do it blindly but should
-inspect it critically and look closely at how the software is developed, what reseach methods are used and 
+inspect it critically and look closely at how the software is developed, what research methods are used and 
 how are results of that software generated. Here are some considerations:
 
 - What is the quality and reliability of software we are reusing? Is it well tested? Some indicators of reliability
@@ -145,7 +145,7 @@ Share your own improvements or extensions to open source projects under the same
 ### Intellectual property and licensing of AI-generated code
 
 The licensing and intellectual property (IP) of code generated by large language models (LLMs) and 
-[AI pair programmers][ai-pair-programmers] (such as [CodeGen][codegen] or [Google Copilot][google-copilot]
+[AI pair programmers][ai-pair-programmers] (such as [CodeGen][codegen] or [GitHub Copilot][github-copilot]
 which operate with an AI system as one of the code developers) raise complex legal and ethical questions that are not 
 clear cut. 
 Discuss as group and write down in the shared document some considerations and pros and cons of using AI-generated code.

links.md

@@ -64,6 +64,7 @@ any links that you are not going to use.
 [free-software]: https://www.gnu.org/philosophy/free-sw.en.html
 
 [github]: https://github.com/
+[github-copilot]: https://github.com/features/copilot
 [gitlab]: https://about.gitlab.com/
 [git-commit-avoid]: https://wiki.openstack.org/wiki/GitCommitMessages#Things_to_avoid_when_creating_commits
 [git-commit-good-practice]: https://wiki.openstack.org/wiki/GitCommitMessages
@@ -75,7 +76,6 @@ any links that you are not going to use.
 [glosario]: https://glosario.carpentries.org/
 [good-commit-message]: https://cbea.ms/git-commit/
 [good-enough-practices]: https://carpentries-lab.github.io/good-enough-practices/index.html
-[google-copilot]: https://github.com/features/copilot
 [google-doc-string]: https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html
 [google-oxford-dict]: https://languages.oup.com/google-dictionary-en/
 [grch-documenting]: https://goodresearch.dev/docs