2020-04-14 - Radovan Bast, Flavio Calvo, Richard Darst, Anne Fouilloux, Pavlin Mitev,
Hasti Narimanzadeh, Pedro Ojeda May, João M. da Silva, Thor Wikfeldt
April 7-8, 2020, we gave our first online workshop on introduction to
Git (2 x 3 hours) with 22
participants and we plan to deliver many more such workshops on a number of
topics based on our lessons.
The workshop went well. Online feels slower, but has a different set of
advantages (we discussed later whether we actually covered significantly less
than during an in-person workshop and we were not sure the pace was actually
Here we wish to share with the community our lessons learned: What worked well
and what we need and plan to improve. We use bullet point format for brevity.
It’s maybe obvious but aiming for less material at a calm pace is better than
trying to cover all material too fast. During the online workshop we will
manage to traverse less material than in-person and it’s good to prepare for
that. For 1 hour session, plan for 30 minutes. The rest will be questions,
issues, and breaks.
Breaks and ice-breaker
- 5 minute breaks were too short, better 10 minutes or longer, at least once an
- We have started with a demonstration of the tools (Zoom and HackMD) and this
was probably time well spent (thanks to Greg Wilson’s excellent
and references therein).
- The HackMD ice-breaker was for each participant to write their name,
operating system, experience with Git, and optionally what they are working
on. We found it useful to pre-fill the HackMD section with the participants’
initials to avoid that all cursors start from the same place and everybody
hesitates to write something.
- We should have included a “ice-breaker” break-out room session where persons can talk
about something informally considering that the first time participants
possibly ever experience a breakout room is in the first exercise (they may not
know how breakout rooms work, they need to find the exercise in the material,
they don’t know anybody). We want people to feel comfortable and to ask
Solving technical issues
Online, the initial problems can end up derailing the whole day’s schedule, and
take longer to get resolved. Compensate by ensuring they are set up in advance,
which is also easier to do online.
- On day 1 we spent some time debugging tech issues and for the next event we
plan to create a 5-10 minute video “setting up and configuring Git” and ask
all participants to show up at a session one day before the workshop to
demonstrate that all is set up to not lose any time during the actual workshop.
- For solving technical problems we found it useful to move the participant
into a breakout room with a helper where the participant can share screen and
this way we could solve problems without disrupting the main flow too much.
- However, if one has previously created groups for group work, the only way
to send helper-instructor pair to room is to delete all the existing rooms
or un-assign all participants. It’s not possible to launch just a single room
out of several existing rooms.
- We think that when pre-making the rooms, you have to create some empty
spares for this.
Without limitations on distance, we can involve more helpers. With more use of
breakout rooms, they have a more clear job and it could be a great opportunity
to pay forward but also learn more for someone who finished CodeRefinery a
little while ago.
- To keep a high quality of the workshop each group should have one
helper/instructor. But this places limits on scalability - we can’t have too
many participants and must maintain a 1:5 helper:participant ratio.
- Helpers were important for our breakout room systems to work. They don’t have
to be the absolute experts: primary instructors can rotate between breakout
rooms and help with hard questions, also having typically more experience with the material
and exercise goals.
- Helpers can be recruited from previous online workshops, and perhaps that
could even be a requirement: “price of workshop is to attend a later workshop
as helper” (not a direct lesson learned from this workshop).
Breakout rooms are pretty good, but as a host, the Zoom mechanics take some
getting used to. We found an interesting semi-flipped classroom mechanic.
- Fewer longer (15 min) breakout sessions were better than many short ones
- This also means that we should group some exercises and not have them spread
out every 10 minutes.
- On day 1 we tried to group participants according to operating systems but we
got better feedback and it felt better after grouping participants either
randomly or even better according to experience.
- Groups with 4-5 persons seem to work well, with one helper.
- In breakout rooms encourage participants to share their screen and other
participants to comment but also make sure that it’s not only one participant
sharing all the time at every group session.
- Some exercises can be done in driver-navigator mode, where one participant
who shares screen types in the commands and other participants in the room
discuss and recommend what to type.
- Some people just wanted to work alone, that’s OK too.
- Method 1: group work
- Most teaching done in main room (this is important for the most important
and delicate topics).
- Participants are in breakout rooms, working independently, sharing
screen/asking for help when they need to.
- Method 2: flipped classroom (“flipped classroom” isn’t quite the right
- Initial motivation in the main room.
- Switch to breakout rooms early to go through the type-along exercises.
- This only works when things are clear enough that people can’t get too lost.
- (*) One learner shares screen, others follow along discussing, asking
question, and typing along themselves. Emphasize “it’s easiest to share
the screen since you don’t have to do the thinking”.
- (*) Instructor flips between the rooms every 1-2 minutes answering hard
questions and following progress.
- Join the end for a wrap-up where best questions are discussed.
- Helpers and instructors should write down the most important questions to
- In reality, use the best of both depending on your specific lesson,
especially the asterisk (*) points!
- Encourage the instructor to cycle through breakout rooms to watch
discussions and help out.
- Many interesting questions were asked in breakout rooms but we did not
write them down, they could have been interesting for everybody. They
should be written down and discussed as a follow-up in method (2).
- Host can lose host rights sometimes.
- Host should not enter breakout rooms, at least if they are not the original
host because then hostship is transferred to original host.
- In our case the person who created the meeting room transferred hostship to
another instructor who then organized the breakout room but we experienced
a technical glitch and hostship fell back to the first person and we lost the
room assignments and for a minute or two the room creator did not even notice
this (was busy helping out a participant). This means that ideally the person
who is the main host should also create the meeting room, if possible.
- Richard: at least when I was main host in another meeting, I could join a
breakout room and not lose host. I think. Needs more testing.
- Co-hosts seem to be able to jump between rooms freely after first joining
the room they were originally assigned to (i.e. can’t select any group from
the main room).
- At one point, Zoom dropped the whole meeting and everyone re-joined
(automatically). Pre-assembled breakout rooms got lost, which was annoying.
HackMD was a vital resource, but you should have someone dedicated to watching it and keeping it organized.
- We were impressed how well it worked, holding up with 25 persons editing
without noticeable lag.
- If a question was too advanced or we had no time to answer it, we encouraged
to write the question in HackMD (or wrote it ourselves there) so that it
could be answered later.
- Asking and replying question in HackMD worked well. It worked so well that
even in physical workshops we should use HackMD for questions that helpers
- It gives the possibility to answer at different levels of complexity in
successive bullets, so that each participant can read until satisfied with
- Students can come back after the course and find better researched answers,
if the in-course answer is unsatisfactory.
- Make sure that the HackMD contents, without any identifying information, can
be made public after the course.
- Instead of asking questions in a particular section of the HackMD and
searching and scrolling it was better to ask questions always at the current
bottom of the document. Add new section headings as you start new sections.
- Some questions on HackMD were a bit off topic (but still very good questions)
and some answers probably looked confusing so some questions can be postponed
for after the video call and answered later.
- Participants should be asked to give feedback after each day at the end of
the HackMD. One positive experience, one thing to improve, as usual.
The chat window in the Zoom client is useful because it can provide multiple
ways to get information for different learning styles. However, it is not
threaded and you have to keep it from getting out of hand. Better for detailed
questions to go into HackMD.
- It helped to direct most questions and answers to HackMD and only short
administrative questions via chat. Participants should not be asked to watch
both the chat and the document.
- The chat can be used for formative assessment questions where participants
are asked to vote for correct answers in a multiple-choice question.
- Practical announcements/instructions should be provided both written and
spoken, to reduce chance they are missed.
- The recommended signals (raise hand, \hand, red/yellow “sticky” notes) should
not only be communicated at the beginning but also written somewhere and
Online, there are more things to think about, but also more ways to communicate
(they go together). To compensate, have enough people and clear roles about who
- We used a private chat as back-channel to coordinate among instructors and
helpers. We kept the chat private to not reveal any personal information we
may need to share but we noticed later that most/all of what we talked about
could have been and should have been public (though not necessarily to
students, but just for reasons of cognitive load). We never needed names and
the only sensitive information were room connection details.
- On day 1 we failed/forgot to assign clear roles to ourselves; we were all a
bit overwhelmed with the chat, plus the HackMD, plus answering questions on
the microphone, plus some of us preparing and giving the lectures. Next time we
- Roles during main lectures:
- Host person in charge of overall schedule, timekeeping, breakout rooms and
Zoom chat/participant reactions, clearing feedback, balancing answering
questions, moderating, etc.
- Instructor and upcoming instructors (they can’t at the same time prepare
their material, follow questions, and do one of the other jobs). One of our
instructors managed to do both: teach and manage breakout rooms, so it is
possible, but easier if somebody else takes the charge.
- One person watching and formatting the HackMD (but more persons might be
needed if there are many questions).
- Backup expert helpers for problems that require intensive debugging (at
least needed at the beginning).
- Roles during breakouts (this is more flexible):
- Host in main room watching stuff.
- One helper per room leading.
- Lesson instructor hopping from room to room answering advanced questions
and also probing the general mood.
- Host makes all instructors and helpers co-hosts so that they can move between
The requirements and recommendations are roughly like in-person.
- Showing history of commands via tmux or similar, coupled with displaying the
- Gray/dark background terminal looked better than light background terminal.
How to make this more scalable?
- This time we did not plan to record or stream but we nevertheless asked the
participants in a pre-workshop survey: 2/20 preferred not to have the
workshop streamed, 1/20 didn’t want it recorded.
- The workshop was great, but we should think more about how to reach more
people. A small workshop where we can individually interact with everyone is
amazing, but the promise of digital technology is that we can reach everyone in
the world. How can we get the best of both? Can we also do something for
everyone else who can’t attend but might want to watch later? This is
something to think about.
- How can we make this more scalable? This workshop was quite labor-intensive.
You could probably do it with two instructors (instructor + HackMD watcher) + 1
zoom expert (host + general helper) + a lot of semi-experienced helpers (1:5
ratio) + a few debuggers to help with tech support the first hour (not
overlapping with instructor or HackMD watcher).
- Imagine if we had main room recorded (or even streamed), but breakout rooms
not. People can still ask and interact with privacy in the small rooms - and
we take these comments/issues back to the main room. Other people following
along later can do the exercises at their own pace, and hear the
intros/conclusions in the main rooms, and it might feel a bit like a small