Recently, I co-organized a hybrid unconference - the Node.js collaboration summit for 2024 H1. This was the first time I participated in organizing an event like this, and I learned a lot from the experience, so I decided to write this blog post, hoping that it may help others looking into organizing a hybrid unconference.

Go to similar events and see how others do it

For an event organizing beginner like me, it’s natural to do some online research and read a post like this before jumping into the organization. I think the most useful resource I’ve found in this regard is the “How We Work” guide from TC39, which contains very detailed guidelines on how to host a hybrid meeting. Still, nothing beats actually going to this kind of events and learning how it is supposed to work.

During the organization, there can be tons of questions about every minute detail, e.g., “How should we sit? How should we use the microphone? How long should the sessions be?”. If you’ve never been to one of such events, it’s difficult to devise good, concrete answers to all these questions. But if you’ve been to some productive unconferences, being in the spot would leave some vivid memory in your brain and help you get closer to the list of things that really matter. When encountering these questions, you can at least try to recall what people did there, and copy the solutions that seemed to create the best dynamics in the room (virtual, or physical).

Of course, not all of these events work well, or there can be moments of chaos even in a generally productive event. That would also be useful because it will certainly leave a bad impression on you. You can observe, analyze, and learn what to avoid.

Sending an interest survey in advance

For a first-time organizer, one of the greatest fears is that the event may not even happen due to a lack of interest or support. To leave enough room for the decision, the lesson I learned is to try reaching out to various parties no less than 6 months in advance, especially if you have the December-January holiday season during this period.

To figure out whether there will be enough attendees at the event to reach critical mass or just what kind of maximum capacity we should be prepared for, I copied what people did in TC39 - sending out an interest survey (in our case, a Google Form). In particular, our survey asked this question:

How certain are you about attending the summit?

  • I’ll book travel for it as long as it’s happening in city, date / I’ve already booked travel
  • I will be in city on those dates and may drop by
  • I may book travel but it’s not certain
  • It depends on whether I am going to an event that is happening in the same city around the same time

This helped us a lot in the planning by giving us a rough turnout estimate. Also, if you know your community well, this will give you a rough idea of what kind of discussions can be had at this event and how successful it will be.

We sent this survey to a private discussion page, some public Slack channels, and some repositories that are subscribed by those who are more likely to commit to attending. This was meant to avoid attracting random people who won’t commit to attending, which can lead to a gross overestimate. The downside of limiting the survey spread is that the turnout can be underestimated (which happened in our case, though not too much), so it’s also important to keep that in mind and leave a bit of margin.

The venues available for booking usually have different capacity limits, so having a more concrete expected turnout also helps choose the right venue. If there is a sponsor to talk to, this data may also be useful for them, especially if catering is sponsored and they need to have an idea about the budget.

In our case, there is also a travel fund that sponsors travelers whose employers won’t cover the travel expenses for a project event like this. In the survey, we included questions about whether the respondents needed funding for travel and their budget estimates. Having the numbers from the survey also turned out to be very helpful when we tried to get the budget approved.

Announcing the event in the right channels

Based on some unhappy past experiences, others had warned us that making registration free and open to everyone could lead to no-shows and wasted resources (swag, catering, etc.). One solution to this problem in the past was setting up a registration fee that would be returned to attendees when they did show up, but that wasn’t very popular. This time, we wanted to give free registration a shot again, so we still made the registration free, but with a few tweaks:

  1. Similar to how we distributed the interest survey, we only publicized the registration in limited channels subscribed by those more likely to attend. This audience may also spread it by word of mouth on social media, which is also cool, and that was also how we got some valuable community members outside our usual bubble joining. We didn’t publicize it through the high-traffic official accounts to avoid attracting those who are more likely to no-show.
  2. For this event, the venue was a space borrowed from a company’s office. Like most office buildings, there are additional security procedures for the visitors at the reception, and we need a way to manage the tiny risk of vandalism/property damage. So we decided to make it open to “all Node.js collaborators, and those who can find a Node.js collaborator to vouch for them”. That seemed to be enough to give our host enough confidence about the visitors we were bringing in, while still making it open to community members we recognized but not e.g. random strangers from the Internet looking for free food or a free entrance into our host’s office.

As it turned out, if you publicize your event to the right crowd and set up the right constraints, making the registration free can be safe.

Preparing a schedule designed for hybrid attendance

The Node.js collaboration summit was meant to be an event attended by those who have been working online with each other and want to “move the needle” or fast-forward certain discussions in person. While it was also cool for people outside our usual bubble to attend it, a past lesson learned the hard way was that losing the focus would diminish the value of the event for everyone - both those who are already in the bubble, and those who want to peek inside the bubble. To this end, this summit was a 2-day event and single track focusing on different aspects of the project, and I think this plan worked pretty well. If it was only one day, we couldn’t discuss much without going multi-track. If there were multiple tracks, the tracks would start competing against each other, leading to less-productive sessions.

This time we only started preparing the schedule about a week before the summit. One of the reasons was that people were still submitting proposals the week before the summit. Another was that we tried to take care of timezones of remote participants and didn’t hound for their timing preferences early enough. Settling down on the schedule a bit late seemed to work out okay, though I think it would’ve worked better if we had a deadline for people to submit proposals and time preferences around 2 weeks before the summit, since that could’ve helped remote participants plan their attendance better.

This summit happened in London, and most remote participants were from the Americas. As a result, the afternoons were when we had the best coverage of hybrid attendance. We decided to schedule the more controversial sessions for the afternoon. The most contentious sessions were placed at the end of each day (the summit was scheduled to end at 17:00 each day, though we could stay in the building until 18:00). I think that was a good call - we expected people to go overtime in the last sessions, and they did. It was nice that folks could still take a few minutes to wrap up the debates instead of having to stop abruptly when time was up.

Providing adequate guides for in-person attendance

Before the event started, I wrote down a detailed guide for in-person attendees, which included things that I wished event organizers would tell me when I attended other events:

  1. If the entrance of the building is difficult to find, provide detailed instructions: in the past, I got lost all the time when I had to go into a giant building to attend an event. For this one, I used a link to Google Maps Street View and added a few extra explanations about how to find the entrance, and it seemed to work well.
  2. Describe the general procedure: where the attendees should go after entering the building, what would happen after they get their badge, what gates they will run into before getting to the room, how they should ask for help if they get lost, etc. This is meant to give attendees some assurance when they do get lost.

The list ended up quite lengthy. So I also wrote that attendees didn’t need to read all these, but they could consult the guide when they had questions. It seemed the guide served its purpose - at least I didn’t see people asking questions about things that were already mentioned in the guide.

Arriving one day before the event and checking the venue

One thing that I was glad that I did was arrive early and check the venue the day before the summit. That helped me a lot in writing the guide mentioned above and tackling a few technical issues that could waste precious time during the summit (like how I should start the Zoom Webinar, how the microphones should be used, etc).

The day before the event is a good opportunity to check the room setup. For a collaboration-focused event like this, a smaller room works better than a bigger room. People feel closer in a smaller room - if the room is too big, putting the tables closer together works, too. Speaking of tables, I found that a setup with round tables or connected tables with multiple power plugs on the tables is important for building a collaboration-focused chemistry. Avoid the typical conference-style podium + rows of seats setup because that can suppress interactions.

During the event, people may need to get in and out of the room: for example, attendees may need to go to the bathroom, or if there are drinks in the room, the catering staff need to know when and how they could come in to get things set up and get things taken away. So the day before the event is also a good time to figure out these routes.

Making hybrid participation work

In the past, hybrid participation at the Node.js collaboration summits tended to be nonexistent. There were some attempts, but almost all that I had been to did not really work. From what I observed, the primary cause was that the remote participants did not really get an equal opportunity to speak, and they were often ignored while others on site were busy with the debates. For this summit, we decided to give hybrid participation a serious try. To provide the remote participants an equal opportunity to speak and make them feel like being in the same room as much as possible, we used Zoom Webinars and the hand-raising feature of Zoom.

Here are the things we did before the summit started:

  1. We scheduled 2 Zoom Webinars, one each day, with cloud recording enabled.
  2. We created a Slack channel dedicated to this summit. Both remote and in-person attendees joined the channel to stay up-to-date with what was going on.
  3. We put the links to the Zoom Webinars everywhere (in the schedule, GitHub issues, slack channels, etc.)
  4. Remote participants who were Node.js contributors or someone we recognized could send us emails in advance, and we invited them as panelists in advance (they got an email from Zoom with a link they could use to join the summit and started talking without waiting to be promoted).
  5. Other remote participants could register in advance and watch the Webinar when it started (for GDPR reasons, we didn’t stream the event). They could ask in the chat if they wished to speak, and we would promote them as panelists.

Maybe we were being too careful, but the panelist-attendee setup was to prevent random people from the Internet from coming in and disrupting the event. Although in the end it seemed we were being too careful and no one tried disrupting the event at all - on the contrary people were all very respectful and would even turn down invitations to the panel if they only wanted to listen.

And, during the summit:

  1. In the room, we used the hand-held microphones as a symbol that signified it was someone’s turn to speak. The sound at the venue would be going through the A/V system on-site via the Node.js project Zoom account hosting the summit, and people in the room must use the microphone to talk. This made sure that remote participants could hear those in the room well (I believe one of the reason that caused failed remote participation in the past was that people did not use the microphone enough and remote participants couldn’t hear well).
  2. To improve awareness of the remote participants, we kept the participant list displayed on the screen in the room. In Zoom, those who had their hands raised would be listed in the beginning of the list in the order in which they raised their hands, which formed a queue.
  3. Everyone who wanted to speak must use Zoom to raise their hands first. In-person attendees were also asked to join the Zoom Webinar as panelists on their laptops, but mute their microphone and speaker to avoid audio feedback issues. Since the in-person attendees also used Zoom, they would be in the same queue as the remote attendees, and everyone got an equal opportunity to speak.
  4. We tried to make sure there was at least someone paying attention to the queue and stepping in when the queue was not respected. There were moments when we could’ve done better in this, but towards the end of the summit, folks seemed to grasp the gist of it, and session facilitators with experience in similar setups were very conscious about the queue.
  5. People who wished to present slides or share screens should do it using Zoom on their own laptops. In the room, the screen displayed what the Node.js Zoom account hosting the Webinar saw. Those in the room could either watch from their laptop (if they were far away from the screen) or watch the screen in the room. Remote participants just watched it from their own computer. This ensured that the watching experience was also equal for those who were in the room and those who weren’t, which was also important (I believe another cause of failure in the past was that presentations were only projected to the screen in the room, and remote participants couldn’t see anything).
  6. We tried to have at least a note-taker at any given time. When no one else was sharing the screen, we shared a screen of the live note-taking page. This was meant to help remote participants (or sometimes in-person participants) quickly figure out what was going on in case they got distracted or only joined halfway through the discussions. We could’ve done better in this; sometimes, there weren’t enough people taking notes. Trying out an speech-recognition-based transcription solution may be cool, but setting it up would require some extra work, so we didn’t manage to do it. We used HackMD for collaborative markdown editing, which worked pretty well.
  7. We had a few coffee breaks and a lunch break each day. Remote participants joining around those breaks may be confused when they see people leaving or arriving. So I tried to announce what’s going on before and after the break via audio, and wrote them in the slack channels too (though I think I still missed a few). I also screen-shared texts like “Lunch Break until 13:45” when we went to the breaks so that remote participants joining when the room was empty could understand what was going on. During the lunch breaks, we turned off the cloud recording and resumed the recording when we were back to avoid recording an hour and a half of silence.

At any given time, this was the typical layout of what got projected onto the screen in the room.

The setup worked reasonably well. There was still room for improvement in terms of respecting the queue and note-taking, but things were generally quite orderly, and I think we didn’t do any worse than what could’ve happened to an all-virtual or an all-in-person event in those regards.

These ideas weren’t anything new - they all came from other events that I had been too. While our particular setup for this summit relied on Zoom, Slack, and HackMD, other events that I had been to used other tools (e.g. Jitsi, Big Blue Button, Google Meet for conferencing; Matrix for real-time communication; Google Doc for note-taking) and those also worked pretty well.

Format of the sessions

Theoretically, in the 2020s, most sessions that happen at this kind of event could also just happen online or asynchronously and do not require everyone to fly to the same place. Still, it’s true that in-person events and synchronous communication can lead to different chemistries and can be a lot more efficient for certain kinds of debates. From what I’ve observed, three types of sessions can really benefit from the special chemistry of a hybrid event like this:

  1. Give a brief overview of what a team or a working group has been working on recently, and seek feedback from people outside the team/working group. It was mostly about spreading information out of different bubbles. This is important to a big project like Node.js, where people usually work only on a few specific areas.
  2. Take debates getting stuck online into the session, present options, and see if it’s possible to fast-forward the consensus-seeking. This, in particular, needs remote participation to work well because it’s difficult to get all the parties involved in the debate in the same spot in person.
  3. Identify specific unresolved issues, discuss the path forward or brainstorm solutions, and test the temperature of these ideas in the “room” (physical and virtual).

The most efficient sessions tend to have an agenda prepared in advance, and aim to come up with clear goals or next-steps.

Some final random tips

  1. Like everything else, the success or failure of an event depends on good teamwork and communication. For this summit with 20+ attendees, we had at least 4 co-organizers that shared the work, and there were a lot of different parties to talk to. There were some moments when we were seriously considering cancelling but those moments could’ve been avoided if we planned earlier or communicated with other parties better.
  2. Remember to schedule breaks between the sessions. 10-15 minute break per 1.5 hour of sessions can work reasonably well.
  3. The lunch break needs to be long enough for interesting hallway tracks to happen but also not too long to take up time that could’ve been used for the sessions. For an event with in-room catering, a 1.5-hour lunch break seems adequate.
  4. Confirm dietary and accessibility needs with the attendees and plan accordingly - this may be somewhat obvious to regular event organizers but not necessarily to event-organizing beginners.
  5. If a group photo is taken, check that everyone is included in the photo.
  6. We discovered that we should at least have two hand-held microphones so that when people in the room lined up, we would not be busy passing the microphone to the next person once the previous person finished talking. When we had more than one microphone, we could pass it to the next person and let them get ready before the last person finished talking.
  7. I don’t know the model of microphones we used but they looked like the classic Shure SM58 and seemed to be unidirectional. When using a microphone like this, while some people (who are probably regular karaoke singers) can work with it very well, other attendees need to be reminded that they must point the microphone towards their mouth for it to pick up their voice properly. People in the room may not tell a difference, but it would show in what the remote participants hear and in the recording.
  8. After the event, it’s nice to write a trip report that helps those who could not make it learn what happened. For this event, I wrote this trip report for the Node.js official blog.