Breakouts: when and how?

Breakout rooms in Zoom are ideal for warming up a workshop and developing a sense of community and belonging among learners. However, most Carpentries workshops are not designed with group challenges the way Instructor Training is. How can we encourage Instructors to make use of breakouts to maximum effect during a workshop?

(There may be some overlap between this and the Helpers topic)

We haven’t tried it yet but we were thinking that for an upcoming R workshop we might check in once per hr or so by splitting the group into breakout rooms with a helper. The helper then could check in with each person individually, hopefully catch up anyone who has fallen behind, and provide an opportunity for folks to ask questions they might not ask to the full group.


I think for the moment we do the best we can, and try to use breakouts to support individual learners as check-ins. However:

Heresy below - but please hear me out!

If this becomes a teaching format we plan to use long-term, we should probably have an alternative version of our materials, which allow for collaborative code editing. This retains the core benefits of peer learning that make our in-person classes so special.

  1. We replace our live coding with a script that learners can execute on their own machine. :grimacing:
  2. We don’t ask them to type (I realise this sounds like heresy, but the bazillion screens and windows are a nightmare for even more experience learners: I tried to edit the code in the zoom window several times, because I didn’t realise it was your RStudio, not mine. was one of my intermediate learner’s comments). It is likely to be a disaster for beginners. :disappointed:
  3. The instructor still live-codes the materials, and explains all of the steps/mistakes/intermediate outputs generated as (s)he goes along.
  4. We then add a whole bunch of formative assessment/challenge tasks, that start with faded examples and build up to fully writing small scripts/tidyverse “pipelines”, which learners work on in breakout rooms as a group. These are commented out in the original script we give them, and which we uncomment and get them to work on throughout the course.
  5. We break them out into rooms (with a helper in each), and get them to use a plain-text website to paste their code snippet into and collaboratively edit (so copy :arrow_right: edit on local machine :arrow_right: execute and play around with :arrow_right: then paste back into the online code editor when it’s working).

Also, for the above to work, we’d need:

  1. A good, Google Docs-like collaborative code editing platform
  2. A pre-workshop flight check for installation issues

Apologies if this is repeated from above, but adding this as an “issue” while teaching Instructor Training.

At our current session, Angela Li and I have had significant difficulties knowing when to bring trainees back from the breakout rooms after group exercises. There doesn’t appear to be a way for trainees to message the host directly from the breakout room, or to send a message back to the main room.

Some options that Sarah Brown has suggested include:

  1. Having learners note in the Etherpad when their group is done.
  2. Instructing learners ahead of time to rejoin the main group when their group is done with the exercise.

We should figure out what to recommend and add that to our documentation for teaching online workshops in general and for instructor training in particular.

1 Like

For this reason it is also important to be sure that learners have access to a written set of instructions that they can access during the breakout session. If they get into the breakout room and nobody can remember what they’re supposed to do, they’re lost.

There are also a lot of unanswered questions about the best way to create breakouts. Creating breakouts manually is time consuming but allows deliberate assignment to all rooms. Randomizing requires that helpers be reassigned manually, and can pose a challenge for creating extra rooms. When a host wishes to shuffle groups, re-randomizing may not successfully accomplish this.

1 Like

Seconded: I tried this at our Python workshop and even though people didn’t really talk, I think it was worth doing to give people a smaller group to ask questions.

IF you do this, need to prep the helpers so that they know it’s going to happen and then how they should lead the discussion in the room. Our participants were quiet, so I wish I’d given the helpers a script - introduce yourselves, ask these specific questions of the learners, and then open it up for their questions (for example).

1 Like

Remember that online breakouts have a very high temporal cost, especially if you’re using chat and participation logos. Budgeting 3-5 minutes for transition as everyone sorts windows, rejoins, re-moves windows (especially if you’re trying to do a half-window view, half-window coding setup) is tricky. I will be trying to make sure my breakouts align to end with a breaktime, rather than trying to teach immediately after rejoining.

We’ve had some success in recent online programming courses (non-Carpentries, but using DC material) that followed some aspects of @dvanic’s model: we cycled repeatedly through three stages:

  1. an introduction to important concepts from the lead instructor, with live coding & explanation
  2. exercises in breakout rooms, with 2-3 learners per room. helpers & instructors dropped in on rooms throughout, at random or after being called on whole-group chat channel.
  3. Q&A back in the main room

Things that worked:

  • communication seemed to be good in the vast majority of small groups. Members seemed to support each other with spotting typos, etc, only asking for help from instructors/helpers if they couldn’t first find a solution within the group
  • learners find the exercises well-worded and easy to understand
  • the model seemed more tolerant of differences in pace between learners than participatory live coding often is
  • helpers/instructors could much more easily provide individualised support to learners

Concerns/things that could be improved:

  • more exercises are needed for a model like this, as @dvanic predicted in her fourth point
  • a minority of people weren’t happy in their breakout group e.g. because the group was too quiet/other members didn’t engage
  • I think it’s a major blow to lose the “participatory” aspect of teaching-with-live-coding. Not sure we can recover from that completely. Instead it’s a question of whether this approach adds sufficient value in other areas…?
1 Like

In a recent Data Carpentry workshop we opted to avoid breakouts (except for perhaps ice breaker) for this reason (time cost for switching). I guess with more time using breakout rooms if becomes faster to assign people non-randomly, but may also take extra time. I think breakouts can still work, especially if the participant numbers are low-ish, there is a helper per room, and one helper to manage breakout rooms (may instructor could do it, but a helper could start ahead of time). I like to mix up rooms, but is seems useful to keep the groups the same for time’s sake.