10  Before the day

Most of what makes a hands-on workshop go smoothly happens before anyone walks in. This chapter is the pre-flight: the timeline you work to, the survey that tells you who is ready, the dry-run that proves the material, and the checks for the morning itself. It pulls together tasks introduced earlier (setup in Part 2, the iteration org and website in Part 3) into the order you actually do them.

10.1 The pre-course timeline

The setup tasks have to land in a sequence that gives learners time to finish the pre-work and gives you time to follow up with anyone who has not. Work backwards from the workshop date so that every due date still leaves a buffer of working days before the day itself. A workable shape, counting back from the workshop:

When (before the workshop)	Do this
~3 weeks	Generate the cohort website, fill in the survey link and due dates, and publish it (Chapter 9).
~3 weeks	Send the first email: the course website link and a clear due date for completing the pre-work.
2 days before the pre-work due date	Review who has and has not completed the pre-course survey.
Pre-work due date	Reach out to explain the next steps (accept the GitHub invitation, clone the setup repository).
~1 week	Give a second due date to finish setup, leaving room before the day.
Second due date	Check who has not completed setup.
1 day after the second due date	Reach out to anyone still stuck to offer support; this should still leave at least 2 working days of buffer before the workshop.
~2 days	Run the pre-flight dry-run (below).

Adjust the exact spacing to your cohort, but keep the principle: every due date is followed by a follow-up window, and the last follow-up still sits clear of the workshop day. The sections below expand the key milestones on that timeline.

10.2 Around three weeks before: launch and invite

• Generate and publish the cohort website, with the survey link and the due dates filled in (Chapter 9).
• Send the pre-course work (Chapter 6) with the website link and a clear due date.
• Open the pre-course survey and share its link (see below).
• Invite every learner to the iteration org from the survey usernames, via the ghclass scripts (Chapter 8).
• Confirm the room, projector, power, and reliable internet (Chapter 5).
• Confirm the room equipment: a whiteboard or flipchart visible from every seat, with markers, for the concept-map fallback (Section 4.5); A3 paper (two sheets per learner) and pens for the concept maps; yellow sticky notes for every seat (the done-signal, Chapter 11); wall space to pin the maps; a pointer or clicker for advancing slides; and ideally a second screen so your laptop, the projector, and your instructor notes are all visible at once.
• Confirm catering or breaks for the four-hour session if your venue needs it arranged ahead.

10.3 The pre-course survey

The survey does double duty: it tells you who your learners are, and it surfaces who has not finished the setup. The reference run used Google Forms: the lowest friction for learners, and a straight export to the table you feed to the ghclass invitation scripts (Chapter 8). If you would rather keep the data fully under your own control, KoboToolbox (https://www.kobotoolbox.org) is the open-source alternative; the questions are the same either way.

At a minimum, ask for:

• GitHub username (you need this to send organization invitations).
• Operating system (so you can anticipate install issues).
• A short self-rating of comfort with R and RStudio.
• Whether they completed the pre-work, with a space to describe where they got stuck.

Tip

Build the survey once and clone it for each cohort. Keep the GitHub-username field as a required short-text question, since it is the one answer the ghclass scripts depend on.

10.4 At each due date: check and follow up

The timeline puts a follow-up window after every due date. Use it to close the gap before the day, not on the day:

• Two days before the pre-work due date, review the survey to see who has and has not completed it.
• On the pre-work due date, reach out to explain the next steps: accept the GitHub invitation, clone the setup repository.
• Check who has accepted invitations, pushed their setup commit, and opened the “Completed setup tasks” issue. Follow up with anyone who has not, by email.
• On the second due date, check who has not finished setup; the day after, reach out to anyone still stuck to offer support.
• Hold a short virtual office hour or offer email support for setup problems, so they are solved before the day, not during it.

10.5 Around two days before: dry-run as the test-learner

This is the highest-value pre-flight step, and it sits near the end of the timeline so any fix you find still lands before the day. Using your test-learner account (Chapter 5), walk the entire workshop as a student would. The example account used throughout this handbook is the test learner rainbow-train (https://github.com/rainbow-train), the test profile of the course author; use your own equivalent. Walk through:

• Clone the material repositories fresh, as the test-learner.
• Complete every hands-on task in the run of show (Chapter 11) in order.
• Open and merge a pull request end to end.
• Note any instruction that was unclear or any step that failed, and fix it before the day.

If you can complete the whole workshop from a clean learner account, the material is ready.

10.6 The morning of

• Arrive early and confirm the projector, internet, and power work in the actual room.
• Log in to your instructor account in one browser and your test-learner account in a second, in Chrome (Chapter 5).
• Open the cohort website and the slides, ready to demonstrate from the point-and-click interface.
• If remote participants join, open the video call and keep its chat visible; it carries their done-signals (Chapter 11).
• Lay out the concept-map materials: A3 paper and pens ready to hand out, a yellow sticky note on every seat, the whiteboard or flipchart clear for the concept-map fallback (Section 4.5). Check your pointer or clicker works.

10.7 A short triage plan for setup problems

Some learners will still arrive with broken setups. Decide in advance how you will handle it so it does not derail the room:

• Identify who is not set up in the first few minutes (a quick “make a commit now” check).
• Pair them with a neighbor who is ready, or seat them near you.
• Keep moving for the rest of the room; do not hold the whole session for one setup.

The real fix for setup problems is before the day, not during it. The timeline above, with its follow-up windows, exists so that the morning-of triage is a safety net for a handful of edge cases, not a plan for the whole room.