From CommunityData

Overall Goals[edit]

We wanted to create an opportunity for our work to help the communities we study and for researchers to form strong connections and a better understanding of community needs. For this first meeting, we decided we wanted the virtual event to be two hours long, including a break. We wanted the event to be in two separate parts, so that if someone could only come for half it would still feel consistent. We wanted to use a video chat service that met the accessibility needs of our audience. We wanted people to have fun, have enough time to talk with one another, and to be able to engage with the content.


For this session, we had a few goals:

  • have speakers who were really excited to speak
  • have two sessions that relate to one another

We tried a few different methods of meeting these and eventually looked over recent publications that people had been giving presentations on. I wanted the our first Dialogue to be easy on speakers, so I liked picking topics they'd been working on recently.

Our schedule was divided into: Presentation; a period for Aaron and/or Mako to add a little contextualization for practitioners; and small group discussions.

Inviting Guests[edit]

We thought about several categories of people we wanted to invite to the event: community organizers (practitioners) who support their communities on the ground day-to-day; people who manage or influence community organizers, keep an eye on communities, or otherwise interact with communities; other researchers; and people who have leadership positions within communities and are concerned with their overall health. We drew heavily from our own social networks.

It was a tough decision to invite people rather than doing an open call. Since this was our first time, we wanted the attendee list to feel manageable, especially as we were planning for time in small groups to discuss how the research relates to their own communities and experiences.

Many, many people who register for a free event don't make it. That's okay! About 50% of registrants attended (including us). Some could only make it for half of the event.


For infrastructure we build the following things:

  • a Google form for registration (email address and agreement to the code of conduct are required, everything else is optional including name, affiliation(s), and what you hope to learn from the session). We also ask people if they have any accommodation needs, and give a few examples (e.g. closed captioning, slides to follow on their own during the presentation, etc)
  • A Zoom scheduled meeting and .ics file, which we upload to the shared CDSC calendar and share with attendees closer to the event
  • A shared Google doc for collaborative note taking during the event. This also includes all the event information, event description, and links
  • Within the Shared Notes Doc there is a place for attendees to put their names, contact information, affiliations, and a few keywords to describe their interests. The document, however, is set to "anyone with link can access," so we also include a warning that the doc is smei-public

Building an Audience[edit]

We do outreach collaboratively between the speakers and organizers. Speakers generally know who they think they should be talking with, and as organizers we maintain a spreadsheet of regular attendees and people we want to reach out to. There are a few email lists we contact as well, e.g. the Berkman Klein email list and the FLOSS Foundations list.

Outreach starts 2-3 weeks before the event and goes maybe too close to the event itself. We're working on being more timely with this. We consider our process semi-open. Anyone can, for example, join our email list where we make announcements. We reach out to a number of people and groups as well and sometimes make social media posts.

We generally have 10-15 people at an event. We believe we could accommodate up to thirty, but might need to reorganize the schedule. (Like maybe put the presentations back-to-back and then have discussion time in two smaller groups that switch at some point.)

Contacting Attendees[edit]

Because we use Google Forms rather than, e.g. Eventbrite, for RSVPs, we sent emails out by copying the email list and seing out messages via BCC. These emails include all the relevant links (zoom link, shared google doc, etc), reminders about dates, etc. We recently started including the .ics file, though I have been thinking about just inviting people directly via Zoom. Since emails come from my northwestern.edu address, I am not confident that other email serves do not filter them out as spam.

More on Logistics[edit]

We generally use jit.si for our meetings. However, the publicly hosted instance of jit.si does not have auto-captioning which can limit the accessibility of meetings. We looked into options, and then decided to use Zoom to host the event (a note on this below).

It was important to me to have a solid Virtual Event Code of Conduct that would help and protect attendees while also meeting our desires for how we want the event to look. We combined several codes of conduct and added a few additional notes that we thought were relevant for the event.

Planning a Dialogue: Timeline[edit]

T-6w: Identify topic, write the 1-paragraph description to share with speaker (and ideally to publish.
T-5w: Reach out to possible external speaker and nail down the date/time.
T-3w: Finalize event description.
T-3w: Finalize invitation lists (e.g., review previous invitee list, add new people).
T-3w (End of week): Send invitations.
T-2w: Finalize the schedule for the sessions (see below for previous scheduling).
T-1w: Send reminders.
T-3d: Finalize handout (if applicable/possible).
T-1d: Send reminder.
T+1w: Post videos and blog post, send thank you emails.

Session Schedule[edit]

This is the scheduling outline that has been used for previous dialogues (that were scheduled for 2 hours).

11:45 - We sign onto jitsi and putter around, check our tech, and have a snack
12 - Cold open (Aaron)
12:05- Brief introductions (everyone says name, affiliation, three words / how they're feeling / other prompt)
12:20- First speaker
12:40 - A little context / Transition (Aaron and Mako)
12:45 - Group Discussion / Q&A
13:05 - Break
13:15- Next speaker
13:35 - A little context / transition (Aaron and Mako)
13:40 - Group Discussion / Q&A
14:00 - End

Things That Could Have Gone Better at Past Events[edit]

I wanted to end with a list of some things that could have gone better. One of our intentions was to have an event, learn, and then iterate. Here are some takeaways:

  • Zoom doesn't do closed captioning in breakout rooms, but it does in the main room.
  • We scheduled a lot of time for small group discussion rather than having a big group question and answer session. Next time, we'll plan either shorter small group discussions and Q&A time, or just have Q&A time as a big group. (Note: We now do bigger group discussions.)
  • We put some effort into sharing information about attendees (and us) with other attendees beforehand. We could have done more of this, which might have been helpful for us as organizers, speakers, and for the attendees to know who they want to talk with.
  • Aaron and Mako did some contextualizing between presentations and small group discussions. We knew other people in the room had a lot of valuable things to say there, and next time we'd like to ask them to participate in this part.
  • Record Zoom to the cloud. Never record Zoom to local.