Instructor Notes
Schedule
2025-10-14: the schedule below does not apply to the new model of the training program and should be ignored. It will be replaced by an updated schedule after we have had the opportunity to gather timings for the new version of the training.
The curriculum is intended to be delivered in 2 parts over six half-days. Part 1 takes 4 half-days and teaches the theory of lesson design as well as implementing lessons using The Carpentries Workbench. At the end of part 1, learners are expected to have an outline for a whole lesson, and a detailed plan for some of its individual sections/episodes. Part 2 takes 2 half-days and teaches collaborating effectively on open lesson development projects. There is an extended break for lesson trial runs between parts 1 & 2, where learners are expected to conduct mini pilots of their lessons with the intended target audiences.
Below is a suggested schedule that can be used as a guideline to plan the content. The timings for each teaching episode vary depending on the audience and the pace so we try not to give suggestions any more as we are likely to be wrong. You should plan to take a break after every one hour of teaching, approximately.
Training Themes
Lesson Development as a Learning Process
A recurring theme in this training is the discussion of the benefits of piloting a new lesson and treating teaching as an opportunity to learn and improve the lesson. We have found it helpful to frame the discussion this way and to draw on our own experience when talking about the ways in which piloting a lesson can help to improve it. For example, when teaching the assessments or narrative section you might discuss a time when you piloted a workshop and realized there was a concept missing in the demo/narrative that learners needed in order to be able to complete the exercise.
Why do we adapt Nicholls’ approach?
We use a modified version of Nicholls’ five phase paradigm for curriculum design throughout the training. Nicholls’ paradigm describes a process, commonly referred to as backward design, where those who wish to develop a new curriculum first begin by defining exactly what their learners will be able to do after they have completed the lesson/training/course. The subsequent stages of the curriculum design process involve designing content to directly meet those stated outcomes.
- Select learning outcomes
- Choose learning experiences to help learners achieve these outcomes
- Develop content to support these experiences
- Assess learner progress towards desired outcomes
- Evaluate chosen outcomes, experiences, and content based on this assessment
The Carpentries community specialises in relatively short-format workshops, typically lasting less than a week and including no opportunities for any assessment after the teaching has finished (a summative assessment). To account for this, our lessons (and this training) place an emphasis on formative assessment: assessment of learner progress that takes place while the teaching is still going on, to give instructors opportunities to evaluate the teaching and lesson content before the end of the workshop. The process we follow in this training reflects that emphasis, giving more attention to the design of these formative assessments (and particularly exercises) as the equivalent to the learning experiences described by Nicholls.
Introduction
Instructor Note
You might like to make a copy of the template CodiMD notetaking page and share your link with trainees so that you can take notes together during the training.
Lesson Design
Trainer Note
Trainees should have received the questions above in advance and arrived at the training with notes prepared. Where multiple trainees are working on the same lesson project, ask for a volunteer or call on someone to represent their team, leaving space afterwards for their team-mates to speak up if their answers differ.
The main objectives of this discussion are:
- to ensure that the members of each collaborative team share a common vision for the lesson they want to create
- to help Trainers and collaborators understand each trainee’s motivation for attending the training and building their lesson
Identifying Your Target Audience
Defining Lesson Objectives/Outcomes
Markdown Table Template for Exercise
You may find this template of a Markdown table useful to share with your trainees before they complete the next exercise.
MARKDOWN
| Objective | Action verb? | Specific | Measurable | Attainable |
|-----------|--------------|----------|------------|------------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |Note: if you are using the template CodiMD for notes, you will find this template table for the exercise included there.
If you are using Etherpad for collaborative notes in your training, you can use the template table for Etherpad instead.
Pushed for time?
The exercise below can be skipped if needed to make up some time. If the Trainer does choose skip the exercise, they should share the link to the Lesson Objective Advisor tool for trainees to try out in their own time.
Example Data and Narrative
Episodes
Designing Exercises
How to Write a Lesson
Trainer Note
To get started on the discussion part, try reading out an interesting response and asking for more detail from the trainee who wrote it. Ask one of the other trainers/helpers to take notes of this discussion in the collaborative note-taking document.
This is a good opportunity to remind trainees about how counter-productive it can be to try to cover more content than the time allows. (See the earlier section on lesson scope.)
Instructor Note
May want to point out that the answers in the current version of this exercise do not have diagnostic power.
The Carpentries Workbench
Instructor Note
Remind learners to paste URL of their lesson repository and the rendered version of the lesson to the collaborative document.
Activating GitHub Pages
We need to tell GitHub to begin serving the lesson website via GitHub
Pages. To do this, navigate to Settings, then choose
Pages from the left sidebar. Under Source, choose the
gh-pages branch, leave the folder set to
/ (root), and click Save. You may copy the URL in
this box, this will be the address of your lesson site.
Orientation for GitHub Novices
- For trainees unfamiliar with the relationship between a source
repository and rendered website, it is important to show the default
version of the lesson website now i.e. before beginning to edit
config.yaml. - It is also recommended to take time at this point to demonstrate step-by-step how to edit files in the GitHub web interface.
Adding Lesson Content
Decide Whether to Teach This Section
We have found that trainees bring a wide range of experience with GitHub to this training. Before teaching the pull request workflow, it is worth checking how familiar trainees already are with this way of working.
If all trainees are already comfortable with opening pull requests to suggest changes to a repository, you can save time by skipping this section altogether.
Reviewing the Pull Request
Ask your co-Trainer to briefly demonstrate the process of reviewing and merging this pull request. Since a more in-depth discussion of pull request reviews is included in the GitHub Skill-up, the demonstration here can be limited to viewing the changes in the “Files changed” tab, writing an approving message, and merging the changes.
Instructor Note
You may ask each trainee in a lesson team to create an episode file for the episode they are responsible for. Encourage participants to use pull requests here, to ensure that they do not create conflicts e.g. by editing the same file or creating files with identical names. Or ask them to observe only and not to follow along while you demonstrate this the first time: they will have an opportunity to practice the steps for themselves in an upcoming exercise.
It may feel awkward to open separate pull requests for the creation of an episode file and the addition of that episode to the lesson navigation, but the cognitive load of teaching how to include changes to mutiple files in the same branch from within the GitHub web interface may be too great. Use your judgement of participants’ familiarity and comfort with GitHub when deciding how to present this and how much detail to go into. Remember that a separate GitHub Skill-up exists to teach them a more efficient way of using the platform to work collaboratively.
Working on the same episode or file - possible conflicts
As we move onto adding more content into trainees’ lesson repositories, it is quite possible that two or more trainees will be working on the same episode. This could lead to conflicts if they are editing the same portion of the episode simultaneously.
Embrace this if it happens in the training! It is a good opportunity to mention to trainees that this is a common scenario when working collaboratively and to guide them through steps that need to be taken to resolve conflicts.
Now may also be a good opportunity to mention that, instead of editing files on the main branch, it is better when collaborators work on separate development branches. This enables them to work in parallel without constantly resolving conflicts and having to deal with them in the middle of ongoing work. While using branches does not eliminate conflicts entirely, it delays them until collaborators are ready to integrate their changes into the main branch. This is done via pull requests (PRs) - which will be covered later in this episode.
Troubleshooting the Lesson Build (~10 mins)
This is a good opportunity to pause and check in on how well trainees’ lesson builds are running. If anyone is having trouble with their workflows, ask them to share their screen and try following the troubleshooting steps to diagnose and fix the issue.
This is also a good opportunity to show what the GitHub actions look like when they are in progress, succeed, or fail if you haven’t already.
If all is well, and you are pressed for time, this section can be skipped.