Jukka Suomela · last updated on June 17, 2021
DISC 2020 — the 34th International Symposium on Distributed Computing — was organized online in October 2020. I took part in the conference organization in the role of the virtuality chair, and in this report I will explain how we decided to set up the first ever online version of DISC, and what we learned from the experience.
Hagit Attiya chaired the program committee, Yoram Moses chaired the steering committee, Fabian Kuhn was the general chair, Moti Medina was in charge of the workshops, and Merav Parter was the treasurer. We had a large organizing committee: Alkida Balliu, Philipp Bamberger, Juho Hirvonen, Yannic Maus, Slobodan Mitrović, Dennis Olivetti, Arik Rinberg, Philipp Schneider, and Jan Studený had volunteered to help us with the arrangements. On top of that, each of the colocated workshops, MoPS Meetings, and Junior–Senior Meetings had their own organizing committees, so overall we had more than 30 people involved in conference organization — huge thanks to all of you!
We had separately paid paper registration and free participant registration. The idea was that there would be exactly one paid paper registration for each paper, and exactly one free participant registration for each person who is planning to take part in the virtual conference. The paid registration covers e.g. LIPIcs publication fees.
Lessons learned: It turns out many authors misunderstood this: they completed the paid registration for their paper, but did not complete free registration to participate in the conference. We had to send reminders to authors who had indicated they are planning to present papers but who had not filled in the conference registration form. The fact that the registration confirmation for paid paper registration looks very much like a typical registration confirmation for conference participation. This needs to be communicated better.
The paid paper registration was outsourced to EasyConferences.org; they took care of e.g. processing credit card payments. Together with the paper registration, we also collected the contact information of the presenting author.
Lessons learned: Make sure that the company handling registrations can handle multiple paper registrations by the same person.
The free participant registration was handled with a simple and lightweight Google Form. A key part of the registration form was that we made sure there all participants agree that the conference sessions can be recorded and the recordings can be published.
This also meant that we could not e.g. fill in registration forms for anyone else, as we needed an explicit OK from the participant for video recording. Therefore we asked everyone, including keynote speakers, to fill in the form.
The basic setup is explained in the brief welcome video that we sent to the conference participants.
The main tool for communication was Zulip. We launched a new Zulip platform (kindly sponsored by Zulip!) at podc-disc.zulipchat.com for the entire PODC–DISC community, and created there dedicated streams for discussions related DISC 2020.
We simulated a physical conference site by creating multiple parallel Zoom meetings. For each day there was one Zoom meeting that corresponds to the main conference room, one that corresponds to the “lobby”, two “coffee rooms”, and two “meeting rooms”. The direct links to these meetings were available in a password-protected web page, and the participants could move freely between these, much like in a normal physical conference. In the lobby room we had a conference timer (using CoSeSy) that showed when the next sessions starts.
Lessons learned: There was not that much demand for various informal meeting rooms, and there was not that much activity in the lobby or coffee rooms. Navigating between multiple meetings in Zoom is not that convenient. Better tools for discovering where there are interesting discussions going on would be helpful. It helps a lot if e.g. the session chair explicitly moves discussions after a session to the lobby or coffee rooms.
The conference talks were short, but for each talk there was a longer prerecorded video publicly available in the PODC-DISC YouTube channel.
Participants were also able to follow talks through YouTube. For the main conference room we created each day a live YouTube stream.
Lessons learned: While not that many participants used the live streams, it nevertheless served as a useful backup plan. It helped participants who had technical problems with Zoom. It helped when you missed some talks—you can rewind the live stream and also watch it then at e.g. 1.5 times the normal speed to catch up.
We used Zoom cloud recording to record all conference sessions. After the conference, we edited the recordings and published them in YouTube, one video per session.
The authors were asked to prepare two talks:
The keynote talks were long live talks over Zoom.
As a backup plan, the authors were also asked to prepare in advance a pre-recorded version of the short live talk, which we can use as a substitute for the live talk if there are technical problems.
For the keynote talks we had a pre-recorded backup version available, and additionally we also had the presentation slides available, so if needed we could show the slides while the keynote speaker connects to Zoom by phone.
Lessons learned: We found the backup videos very useful. There was e.g. an author who could not present due to a power outage, and thanks to the backup video we were able to run the session smoothly. Backup videos also helped to make sure that the authors have thought about their short talks and practiced it; even though the time slots were very short, almost all authors were able to follow the schedule.
We used Dropbox File Requests to upload all files. For each talk we created a new Dropbox File Request, and emailed the link to the authors. The authors did not need to have any user accounts; they could simply use a web browser to upload the files.
I took care of uploading videos from Dropbox to the PODC-DISC YouTube channel. We used YouTube also to store the backup videos (as unlisted videos).
There was a dedicated technical chair for each session (one of the conference organizers). The technical chair was responsible for making sure the session runs smoothly from the technical perspective. The duties of the technical chairs included e.g. the following:
As the technical chairs took care of Zoom-related details, the session chairs were able to mainly focus on the usual chairing duties: opening and closing sessions, introducing speakers, keeping track of schedule, taking questions, etc.
Lessons learned: Technical chairs were absolutely critical, but the amount of work per talk is relatively high. Many technical chairs are needed, at least one per session.
We purchased 10 × Zoom Business accounts, 1 × large meeting add-on, and 500 GB of cloud recording space for one month. We used one Zoom account per parallel Zoom session.
These Zoom accounts were used to create the meetings and they were the initial hosts of the meetings. We configured the accounts in advance according to the needs of different meetings, paying attention to the following features: participant video, auto-saving chats, co-hosts, screen sharing, nonverbal feedback, annotation, whiteboard, breakout room, join from browser, live streaming, email if joining before host, local recording, cloud recording, automatic recording, host can stop/pause, and the region from which most participants are coming.
Our setup for the conference room was that only co-hosts can share screen. Therefore technical chairs made the speakers and session chairs co-hosts as needed.
We had some extra laptops distributed among the conference organizers, and on those laptops we used the conference Zoom accounts to launch the meetings each morning. The coffee rooms etc. were then hosted from these laptops, while the technical chairs took care of hosting the main conference room.
One highly annoying feature of Zoom is this: only hosts can make others co-hosts. It is not possible for a co-host to make anyone else a co-host. Therefore care is needed to correctly pass around “host” privileges from one technical chair to another.
Lessons learned: Zoom sessions that contain only the host as a participant get automatically closed in 40 minutes. A workaround is needed for live-keeping the sessions, especially for coffee rooms etc. that might have no participants. We logged on to each Zoom meeting from a web browser to ensure there was at least one other participant in each meeting all the time.
We organized a full rehearsal session with all technical chairs on the week before the conference. We used exactly the same Zoom setup as in the real conference, and tested also all of our backup plans: connecting by phone, playing backup videos, removing Zoom bombers, etc.
Lessons learned: Rehearsals are critical. We learned a lot during them. For example, playing a backup video is something that does not go well unless it is practiced in advance.
We had configured Zoom so that we record the speaker, gallery view, and shared screen also separately, we enabled the feature “Automatic recording: Record in the cloud”, and we disabled the feature “Host can pause/stop the auto recording in the cloud”. In our tests this worked flawlessly and ensured that we did not need to touch any settings related to recording during the conference (and recording-related controls were not even available in the Zoom client). Unfortunately, in one of the workshop sessions one of the co-hosts managed to stop recording during nevertheless; the recording was lost, and Zoom support was not able to help us. We had to resort to the recording of the YouTube live stream as a substitute.
Lessons learned: Zoom cloud recording is not reliable. YouTube live streams are a very useful backup plan.
When editing the recorded videos, I learned that Zoom cloud recordings are stored in an unusual format. There are apparently very few key frames, and editing them with normal video editing tools is very slow and cumbersome.
Lessons learned: If you are using Adobe Premiere Pro, use “proxies”, it makes a huge difference.
One of our biggest concerns was that the free participant registration would make it too easy for anyone to register and join the conference, just to cause as much trouble as possible. Fortunately, nothing bad happened, but I do not know if we were merely lucky.
We tried to sanity-check all registrations manually before sending passwords to the registered participants.
Lessons learned: Manual sanity-checking is lots of work and very hard. Participants with official university email addresses are easy to handle with whitelists, but very many people registered using e.g. Gmail addresses, and many participants were e.g. new students with no online presence. A better solution is needed.
In our technical rehearsals we practiced the procedure for removing participants who are disturbing sessions. Our plan (that we never needed to resort to) was this: