Updating content

Author: murphyqm

_quarto.yml

@@ -6,7 +6,7 @@ website:
   announcement: 
     icon: info-circle
     dismissable: true
-    content: "**Alert** - this is a pre-release draft; please excuse errors or typos."
+    content: "**Alert** - this is a pre-release development version; please excuse errors or typos."
     type: primary
     position: below-navbar
   title: "Research Software Development in Python"
@@ -44,6 +44,9 @@ website:
       contents:
       - releases/releases.qmd
       - releases/practical6.qmd
+    - section: "6. Conclusion"
+      contents:
+      - summary/summary.qmd
     - href: index.qmd#citation_1
       text: "<b>Cite this material</b>"
     - href: https://www.leeds.ac.uk/about/doc/accessibility-statement

heading_converter/pixi.lock

@@ -21,3 +21,5 @@ heading_converter = { path = ".", editable = true }
 
 [tool.pixi.dependencies]
 jupyter = ">=1.1.1,<2"
+isort = ">=6.0.1,<7"
+pipreqs = ">=0.4.13,<0.5"

heading_converter/pyproject.toml

@@ -7,6 +7,7 @@ date: 2025-06-24
 author:
   - name: Maeve Murphy Quinlan
     affiliation: University of Leeds
+    orcid: 0000-0003-2958-1008
     affiliation-url: https://arc.leeds.ac.uk/profiles/maeve-murphy-quinlan/
 citation:
   url: https://murphyqm.github.io/research-software-development/
@@ -95,8 +96,27 @@ Note that this is an intensive course that covers a lot of content. If you are a
 | Presentation: Testing | 20 mins | Introduce testing workflows | 10.20 am (followed by 5 min break) |
 | Practical 5 | 30 mins | Write a basic testing suite | 10.45 am |
 | Presentation: Releasing and archiving your code | 30 mins | Discuss the importance of creating releases and minting DOIs for your code; discuss exporting record of environment alongside results | 11.15 am (followed by 10 min break) |
-| Practical 6 | 30 mins | Releasing and archiving your code for reproducibility | |
-|   |  |  | |
+| Practical 6 | 30 mins | Releasing and archiving your code for reproducibility | 11.55 am |
+| Summary and Q&A | 35 mins | Reviewing material covered | 12.25 pm |
+
+:::{.callout-tip collapse="true"}
+## Delivery guidance
+
+This is a challenging course to deliver, as there are many tools involved. The following notes have been compiled over the iterations of deliveries of previous versions:
+
+- In advance of the course, run through the practical material to ensure everything still works. Updates etc. can lead to unexpected errors
+  - Don't make things more difficult for yourself by improvising and trying out new things in front of a classroom for the first time...
+  - But equally, it's perfectly valid (and a good idea) to model *not* knowing things: it's better to offer to find an answer and post it somewhere shared at a later point, rather than making people sit through you live debugging.
+- Prioritise delivering the presentations and answering questions and discussion points; it's ok to ask attendees to complete a practical *after* the session.
+  - The practicals build on each other so you can't skip an earlier practical and then do a later one and expect this to work. HIghlight this to students when assigning "homework".
+- **Live coding** does **not** work:
+  - It's inaccessible, ineffective, and stressful for both the person delivering and the audience.
+  - It's ok to run through examples live on the screen as a recap or summary, or in response to a specific question, or when demonstrating steps in the practical, but it's important to note:
+    - Your typing on the screen should **never** be the *only* information source for important or key steps in the process: anything you do on screen should be also documented in the notes.
+    - The attendees should be given time to work through the practical sessions while you provide support, rather than sitting transcribing/copying what you are doing on screen.
+- Note any errors in an issue on the GitHub repository for this website immediately after the course: you will likely forget if you leave it until you have time to update the materials.
+
+:::
 
 
 ## Author's Note

index.qmd

@@ -5,7 +5,6 @@ title: "Practical 1: Gathering Requirements"
 
 ## Activity Overview
 
-**Duration:** 15 minutes  
 **Goal:** Practice translating research needs into clear software requirements
 
 **Why Requirements Matter in Research:**

introduction/practical_1.qmd

@@ -5,7 +5,6 @@ title: "Practical 2: Folder organisation"
 
 ## Activity Overview
 
-**Duration:** 15 minutes  
 **Goal:** Set up a sensible and tidy project folder structure
 
 :::{.callout-note}

project_org/practical2.qmd

@@ -5,7 +5,6 @@ title: "Practical 6: Archiving a release"
 
 ## Activity Overview
 
-**Duration:** 20 minutes  
 **Goal:** Create a release
 
 :::{.callout-note}
@@ -180,4 +179,10 @@ It's a good idea to run your test suite at this point just to make sure everythi
 On your main repository page:
 
 - Your README should now have a correctly formatted badge with a DOI, linking to your Zenodo repository;
-- There should now be a section on the sidebar linking to your release, your license, and a "Cite this repository" shortcut.
+- There should now be a section on the sidebar linking to your release, your license, and a "Cite this repository" shortcut.
+
+:::{.callout-note}
+## Well done! You've created your first release!
+
+Now you have a citable piece of software with a DOI. It's a good idea to now go back to your CITATION.cff file and add in your DOI there!
+:::