It may be the Age of the Pandemic, but as someone who works in tech communities I still find myself going heads down to plan a technical conference that we’re planning on having in person toward the end of the year, with contingency plans. I’ll talk a little more about that aspect of event planning in a later post, for now I’m going to be ramping up on a few common themes between virtual, in-person, and hybrid events. The first one that I’ll be discussing is “ChatOps”.

Transparently, I started this post as “Discord for Tech Events”, thinking about some of the Discord configurations I’ve seen that come up over the course of “OH NO WE WEREN’T PLANNING ON THIS” over the past year that still worked out really well. When I started drafting, though, I realized a few things:

1. The Discord configurations were, and are, really neat but Slack is still the most common tool I’m encountering.
2. Sometimes conferences will just use the chat feature(s) built into whatever their virtual platform of choice is.
3. Figuring out whether you want to use the chat that’s built in vs an external tool, like notably Discord or Slack, requires figuring out a little bit about what you want to do.

With all that in mind, I started drafting out the thought process of the considerations I had when figuring out how I wanted to handle digital participant chatter. Full disclosure: I started this from a space of wanting to use either Slack or Discord, and then scoped out a little to include the benefits of built-in chat platforms as well. I also am assuming tech events primarily becauase those are the ones I’m most familiar with and also because I’m not familiar with many communities outside tech (and possibly gaming) that use these tools as heavily as we do. That said, if the post helps you and you are not in these spheres, all the better.

Source: I found this one on Imgur. Chosen for artistic effect rather than utility, insofar as Dyson Spheres are concerned.

What to Consider for your Conference Chat Platform

Who is at your conference?

First need to consider “who is at my conference”. There is more to a conference than attendees / participants. Let’s cast the widest net, and then move inward:

• Attendees / participants
• Organizers and volunteers
• Sponsors
• Speakers
• Event staff, to clarify:
  • In person events: anyone who is taking part in running the event, but who is not an organizer or volunteer. This can be roles like catering, AV, maintenance, and so on. Typically at an event venue there is a point of contact coordinating with one or more of these groups.
  • Virtual events: this may be a tech support person or team that is available to assist with use and issues on the virtual platform.
  • Hybrid events: would have a mixture of the above roles.

Why am I so precisely outlining who is “attending” the event, beyond the traditional sense? Because the next step is figuring out which groups need to communicate with each other, and what they’ll need to communicate.

How do they need to interact?

The “what” is extra important, because it introduces the concept of “private” or possibly “protected” communication. What’s that? Well if you think about it, some of the communication can and should be open to the event overall, for example participants discussing the talk on the main stage. Other forms of communication should not be open to the event overall, for example if someone needs to report a Code of Conduct issue or violation, or if they need assistance that just generally needs to not be public.

To break this out in a few clear categories, we have:

• Event discussion, healthy debate, etc. This includes:
  • Attendees interacting with each other.
    • This can include Open Spaces or a similar concept with a virtual component.
  • Speakers interacting with participants during their talk and the overall event.
• Event logistics
  • Organizers communicating with staff about food, AV, etc.
  • Organizers, sponsors, and/or staff coordinating booth set up and related activities.
  • Organizers, speakers, and/or staff coordinating the talks and related activities.
  • Organizers communicating with each other.
  • Speakers communicating with each other, if needed.
  • Sponsors communicating with each other, if needed.

Looking at these types of communication, you can see as an event mod you’ll also want to break down what should be private vs what can be private. Lots of correspondence can be private, but as an organizer you will also want it to be moderatable, that is, if something happens that shouldn’t you want it to be visible to you so you can take action. So as an additional set of considerations:

• How do I ensure that conversations are moderatable in the chat platform?
• What conversations need to happen that are possibly private, like Code of Conduct conversations?
• What conversations need to happen that are not necessarily private, but can contribute to overall noise?
• What types of conversations are interactive, and what are not?
  • e.g. Announcements are not (necessarily) interactive and need to stand apart from the rest of the noise, whereas a job board would need to be interactive / conversational.

In the sense of moderatable conversations, running the previous list of concerns through the questions, you can see that:

• Communications between organizers and literally any other group have the potential to need to be protected, as there may be sensitive issues brought to their attention from any other group.
• Communciations between organizers, event staff, and/or sponsors/speakers outside of those protected conversations likely do not need to be protected, but will significantly contribute to the noise of the platform if left open.
• Communications between subgroups, e.g. speakers with each other or sponsors with each other, may not need to be protected in the “private” sense, but may give these groups a chance to talk to each other without, again, increasing the noise of the platform overall.
• Communications between participants and each other likely do not need to be protected, and for ease of moderation should not be, unless you are introducing private rooms for underrepresented groups to exist outside the view of the overrepresented groups.
  • When configuring this, note that these still need to be moderatable and you might be limited to how many you can create based on the diversity of your organizer team. Basically, you need an organizer to be present to moderate but if you don’t have any moderators with the appropriate intersections you’re defeating the purpose of the protected space.
• Communications that need to be “boxed”, after a fashion. This is common with Open Spaces, Birds of a Feather, and similar concepts: there is a conversation that needs to happen in the subset of a space, and not be overwhelmed by the broader space.

How do I use these questions to drive decisions?

So at this point many, if not all, of us have attended a virtual event, or needed to interact with co-workers at $DayJob via a chat platform - and probably Slack with a dash of Discord at that. Because of this, I’m going to assume that everyone is familiar with Channel Explosion, or the idea that you have a channel for what feels like every idea that was ever had. You might find yourself struggling to keep up with what channels you should watch regularly, occasionally check, or completely ignore.

And because we’re all familiar with this, that means that you, conference organizer reading this post, also have experience and empathy with this. Experience that you can use.

When designing the chat platform, do you want to:

• Create the channels you want to create, and limit channel creation so no one else can?
• Do you really, really want to create a channel for general, all the stages, all the separate speakers, all the separate sponsors, etc.?

Basically: do you want 50 channels and if not, how can you design to avoid that? This will be very Choose Your Own Adventure process.

Source: The Twitter banner of the Choose Your Own Adventure book series Twitter account.

The answer is, probably not. And what “a lot” of channels is to a team (or conference) of 10 is very different than a team (or conference) of 10,000. This is why for the most part I’ve tried to stay very abstract, the idea here is that you’re going to run your own conference, event, etc. through the above decision tree and have it help you yield some conclusions.

A specific use case

DevOps Days Buffalo is one of the many DevOps Days, but this one happens to be the one that I’m an organizer for. We’re on our third year, which means that while our first year was a “bootstrapping” year, that

2020 kinda …

ruined …

Source: This Is Fine Dog, of Internet Fame. Drawn by The Nib.

Anyway.

It does mean that I can use a real world example to filter hrough the above. Due to how Everything Happened, this also means we’ve essentially had “three” year ones: a traditional in-person event in 2019, an unexpectedly fully virtual event in 2020, and a hybrid event that we’re planning for 2021. The latter still means that like 2020, and unlike 2021, there will be a lot of chatter between organizers and non-organizers to coordinate in a Slack or Discord to coordinate rather than in person communication like we did in 2019. Some considerations for us:

• We’re about 200 participants, max, and so we’re more on the “10” side of “10 vs 10,000” example given above. This means that we should optimize for reducing channel quantity as much as possible.
• Organizer chatter, since it will be high in volume and also unpredicably contain sensitive information (COC issues, if they happen), needs to be private.
• Speaker chatter does not need to be private, but we want to give them a “water cooler” to chat if they would like as well as to communicate directly to the organizers about day-of logistics.
• Sponsor chatter also does not need to be private, but they will similarly need to have a channel to communicate day of logistics ot the organizers.
• If there is an in-person component with a venue, there will be a single point of contact for them speaking ot a single point of contact on the organizer side. This will likely not be in the Chat platform but will be whatever these two feel is most effective.
• Organizers will need the ability to make announcements that are not buried in the regular event chatter.
• Usually our confernece features a job board. We can do this either via a chat channel or some other mechanism, to be determined. For now I’ll make that a channel.
• Participants will need a way to ask speakers questions about their talks.
• Participants and sponsors should also have a way to communicate

Starting here, this means that our channel list is currently:

• 🌏#general
• 🌏#job-board
• 🌏#announcements
• 🔒#organizers (internal)
• 🔒#speakers (+organizers)
• 🔒#sponsors (+organizers)
• 🌏#speakers (+all)
• 🌏#sponsors (+all)

Current channel tally: 8

Also a feature of DevOps Days is Open Spaces. If we’re doing those Open Spaces either partially or fully virtual, those are going to be our boxed communication. In the past we’ve had three sessions of about four concurrent Open Spaces, or 7 Open Spaces per day. With a virtual component that has a channel, relevant to this conversation, that is about 14 channels. Don’t panic though, those can easily be named using a pattern, such as:

• 🌏#open-space-{topic}

Since the discussion and voting for what Open Spaces to have is a separate, boxed, conversation there will likely need to be a separate channel for that.

One final consideration for Open Spaces: they are usually, well, open. This means that participants can pop in and out of them at will. If you find a discussion isn’t going the way you thought, or that your curiosity about another space is overwhelming, then you can leave your current space and go to another one. That is the logic behind making this channel public. There may be times when you want to make an Open Space private though, for example if there’s going to be a discussion on payment or social justice initiatives that may be open to the room but not the conference at large and should not be searchable later. For ease, I’d keep whatever naming pattern the same just make the approprate channel(s) are private.

Current/final channel tally: 23

(This is the 8 channels initially mentioned, 14 Open Spaces, and one Open Space planning channel.)

Making Use of User Groups Instead of Channels

User groups in the chat sense is more than a little different than User Groups in the tooling (e.g. Hasicorp User Group) or employee (e.g. LGBTQIA+ Group) sense.

Source: A picture of Flavor Ice from this Eater post. No reason. It’s group-like. Also, Flavor Ice and summer go together like, well, Flavor Ice and summer.

This is something to consider when trying to streamline your channels the way we are. There are times when someone may need to talk to a specific sponsor group, or ping the organizers at large instead of remembering which <10 names or so are the organizers vs everyone else. Since we didn’t want to have separate channels for

Anyone at the conference will likely need to reach out to the organizers as a group or a specific group of representatives of a sponsor. Rather than have channel explosion for these, since we have one channel for organizers and one channel for all sponsors, it’s helpful to have a user group or alias (term may vary between platform) so people can @organizers or @{name}-sponsor. To do that, we configured exactly these.

In our case we were not using a specific group for each talk or similar, because with rare exception there is one speaker per talk so people can reach out to those speakers in the Q&A type channel for speakers + participants.

Configuration Details

After all of that you might be thinking: COOL, NOW HOW DO I BUILD IT?

Today is your lucky day, this is the “how do you build it” portion of today’s blog post. When I describe the “how” I’ll be doing some show and tell, but I’ll also be heavily linking to the source documentation for each product.

Slack

First things first, I’ll do an initial configuration in Slack. This will be the initial setup and all the permissions that I want to set before I start inviting users.

Create Channels

Creating channels is relatively straightforward in Slack. In a new, empty, account:

For our channels that I indicated above in the individual case of DevOps Days Buffalo, the rooms might look a little like this:

Slack’s documentation outlines the step-by-step for channel creation.

Setting up permissions

Slack doesn’t have a sophisticated sense of “roles”. There are:

• Owners
• Admins
• Guests
• Everyone else

This means that the permissions that Slack allows you to set are combinations of these, where it’s either Owners, Owners and Admins, and Everyone either including or excluding Guests. What is a guest? A guest is a role that you usually see in paid Slacks, for example in a company Slack. So you might want a customer or client or partner to have access to your Slack for communication purposes, but maybe not to mingle with the employees in general. That’s what “Single” and “Multichannel” Guests are.

For a conference, you will mostly likely have a free Slack and most likely only be using the Owner, Admin, and Everyone Else scheme when configuring permissions.

Choose the workspace owners and admins

The workspace owners and admins should be limited to the conference organizers and volunteers. When setting permissions, you should have more than one owner for redundancy, but depending on the size of your team you might want all organizers to be owners and all volunteers to be admins. Then permissions should be set for both owners and admins, so that the whole group can perform moderation activities.

Limit who can use @here et al

Limit who can use @here, @channel, and @everyone to just owners and admins. Or you will get a lot of noise. (Documentation)

Limit who can approve new users

It used to be that you could limit who even sent the invites (thanks, Slack 🙃 ), but right now you can still who makes it into the workspace based on admin approval. In terms of roles, that means only workspace Owners and Admins can approve invites. Depending on your anticipated volume, you’ll want to either have these post directly to your #organizers channel, a separate channel, or have Slackbot DM the organizers separately. In the case of an event, I wouldn’t choose that last one in case there needs to be a discussion thread in response to the invite. (Documentation)

A note on Slack Connect

Slack Connect is a feature that allows users in different Slack organizations to connect with each other without formally joining each other’s Slack org. An example of this might be a Slack for an IT consultancy connecting to the Slack of a client via a Slack Connect rather than adding an individual contractor or contractors to the client’s Slack as separate accounts. This is a paid feature to use, but paid Slacks can connect to free Slack organiztions. Allowing people outside the conference to interact with attendees inside the conference is something that would be difficult to moderate - anyone outside the conference hasn’t agreed to the confernce’s Code of Coduct and you won’t be able to easily remove a lot of external users en masse. Just to be really clear: even though it is a paid feature it is possible, at least at the time of writing this, for a paid Slack to connect to a free Slack.

Slack does have documentation for what Slack Connect is, but makes it a little difficult to know how to disable it. To disable Slack Connect, you just need to disable the DMs setting in Settings & Permissions:

Cannot Flush Existing Slack Members

Not a hard stop, but something to be aware of: there is no way to “automagically” bulk remove Slack members from an organization. This means that once you add people to your conference Slack, that they are most likely in that Slack in perpetuity unless they are removed on a one-off basis for some reason. The alternative is to set up new Slacks for the conference every year, but that can add a lot of confusion. Especially if the conference has a lot of repeat participants, sponsors, organizers, and/or speakers.

Header Source

Header image of this post is an image of the Star Trek Communicator Prop from The Wand Company.