Last weekend my good friend Jos van Schouten and I presented a session in the Community devroom at FOSDEM. Between the two of us we've run a lot of events. And we’ve learned this: when someone violates your Code of Conduct, what makes all the difference is whether the organizers are prepared to act.
Today almost every event has a Code of Conduct. We weren't going to cover what makes a good document, or why it's there, instead we wanted to talk about the moment nobody likes to plan for.
We quickly made a disclaimer that we wouldn't cover what happens when someone breaks the law at your event either. Something that I unfortunately have experience with*.
Preparing for the worst
Most organizers don’t like to think about this part. We spent months planning the conference, worrying about schedules and speakers. Is there enough food? Will the Wi-Fi be good? But when the Code of Conduct gets mentioned the room gets quiet.
And it’s not because we don’t care. We care a lot. We’re afraid to get it wrong. We tell ourself things like:
“Our community is nice”
“Nothing like this ever happens here”
“It'll be clear how to act”
Famous last words.
When something does happen, the hardest part isn’t offense itself, it’s the scrambling to respond. Because:
- Who should respond?
- What's the right time(frame)?
- Who needs to be involved?
- Who should not be involved?
- What do we tell the person reporting an issue?
- What do we tell others?
When the answers to these questions aren’t clear beforehand, organizers freeze, defaulting to waiting. Waiting to get more info, waiting to be sure, waiting to talk to someone else….
This only gets harder when power is involved. What if the person reported is a keynote speaker? The platinum sponsor? An organizer?
But waiting is not a neutral action. From the perspective of the person reporting it feels like you’re not taking their experience seriously. Even if the final decision is technically correct, trust is often already damaged.
Let's look at some scenarios
To make the above concrete we’ll walk you through 2 real world scenarios, complete with lessons learned and implementation suggestions.
Anticipate opinions
An integral part of a Devopsdays event is Open Spaces, a type of unconference, attendees can suggest topics they want to discuss with others, no slides, no presentations, just discussion. At a 2023 event one of the topics was around hiring more women, and in hindsight we should have had an organizer or member of the CoC team present in the room, since we could expect Opinions™.
Sadly we didn’t, and we had to rely on what people who had been in the room told us. Nobody reported an incident, it was more of a “hey, someone said that in the Netherlands, women with a headscarf are hired over more qualified (men) and that positive discrimination is not right, and it was uncomfortable”. We addressed the topic on the main stage: “we don’t appreciate comments suggesting marginalized groups receive preferential treatment regardless of skills on the job market”.
Lessons learned:
- When possible, have all organizers briefed on the Code of Conduct, and always one organizer present per breakout room. When short staffed, think what topics might be “controversial”.
- For Devopsdays events we already scheduled a meeting with all the organizers and volunteers to talk about the Code of Conduct and other "Know Before You Go" items, one week out. Over time we added scenarios, to which the above was added. Ultimately we started having open conversations about what we could expect to transpire at our event and how we'd deal with different situations.
Global events have local effects
One such situation was the following. For Devopsdays Amsterdam 2024 we knew that global events created strong emotions in communities, especially ours.
One of our sponsors had teams directly affected, being headquartered in Israel, meanwhile in Amsterdam there were ongoing protests on the situation in Gaza. As part of our preparation we decided to talk about a few "what if" scenarios with the team.
If someone in the audience would interrupt the sponsor’s pitch with a statement like “Free Palestine”, the MC would know their line, and 1 of the Code of Conduct team members would find the person later to remind them that interrupting a fellow community member just doing their job is in violation with our Code of Conduct.
We wanted the sponsor to know that the organizer team has their conference experience in mind, and they can proceed knowing we’ve got a policy for handling with the situation. Our sponsor replied that they had had some unpleasant experiences at other conferences and they were thankful that we had reached out preemptively.
The sponsor was not interrupted during their time on stage, and they didn’t report negative interactions.
We prepared similarly with an Israeli speaker, but they couldn’t make the event in the end due to the restricted air travel out of Tel Aviv.
And in 2025 we had 2 Israelis join the team. We wanted to make sure they where aware of, and comfortable with our view on how we’d deal with possible comments. The event went off mostly without a hitch, one speaker wore a keffiyeh, but since we discussed buttons / patches with flags, we felt this was similarly covered and allowed.
Other (Devopsdays) events have opted to avoid accepting sponsoring when the company is registered in a country currently in conflict because they didn’t feel like they could guarantee everyone’s safety.
An event taking place in a university comes to mind - students are typically more active in demonstrations, and their event was likely to attract a large student audience. Only part of the venue was reserved for the conference, which introduced additional challenges when it comes to crowd control.
They anticipated friction and didn’t have the manpower in terms of number of organizers, nor the budget for external security, to actively monitor interactions.
Lessons learned
Your mileage may vary: you might decide differently, but the point we’re trying to make with this talk is that you should think through and decide on the boundaries your team commits to.
Clarity beats completeness; perfect is the enemy of done
When we talk about preparation, many people immediately think about writing the “perfect” Code of Conduct. And looking critically at the document and adjust when necessary is a useful exercise, but that is not the point. The Devopsdays Amsterdam team added language around the use of facemasks after attendees were harassed about wearing them since "COVID is over".
Your (organizers) team should be clear on the following:
- How can someone report issues?
- Are reports named or anonymous?
- What happens after a report is received?
- What possible actions can result from a report?
Most of these options come with trade offs. Named reports are a lot easier to follow up on. But they can feel risky for the person reporting. Anonymous reports can feel safer, but they are way harder to act on.
A named Code of Conduct team is an absolute must-have, ideally with a described escalation path (in Devopsdays' case: the Core team). Knowing who you're reporting an issue too increases trust. You're not sending your concern into the void.
Who is who in the zoo
One of the most important things you can decide on beforehand is who is responsible for what. A lot of conferences say “in case of an issue, talk to any green/orange/org shirt”. Does that mean they take the report, or does that mean they’ll walk you to the CoC person in charge?
When someone upset approaches you, they may just want to vent and tell their story to the person right there.
We advocate for a separate Code of Conduct team whose main if not sole responsibility is handling and responding to potential reports.
It’s also important to decide who should not be involved. Not every organizer needs to know every detail. Limiting information is also care. Receiving reports of someone being harmed is emotionally taxing.
Suggestions
- Create an “on-call” schedule for your Code of Conduct team members. The role is not only passive, waiting for reports of wrongdoing to come in, it requires vigilance. You might anticipate one session that is more controversial, you’re scanning social media for your hashtag to not be associated with a negative message, and then there’s the dealing with actual reports. For the annual PostgreSQL Europe conference we have a Code of Conduct phone. In 2025 the 4-person team took turns carrying it around.
- When creating your team, make sure you have a good mix of genders, employers, and ensure there’s at least one person on the team who is not an organizer. Organizers for community events wear many hats / are typically spread thin as it is during the event, but more importantly someone might have an issue with an organizer, and won’t feel comfortable “ratting them out” to their peers.
Practice makes... better
Practice is where preparation helps you make confident decisions in the moment. But it can feel kind of uncomfortable. By practice we don’t mean role-playing, but sitting down as an organizing team and writing out scenarios. Literally, on paper.
A concrete example is to write down three short scenarios, not detailed scenarios, but like prompts. For example:
- A report comes in about a speaker during the event
- A sponsor behaved inappropriately at a social event
- An organizer is named in the report
These are all good starting points. If you’re unsure, reach out to communities and conferences in your area and talk about the type of incidents they had dealt with in the past, or look at incidents that were reported at your own conference in the past.
After you’ve written down a few scenarios, talk them through. Who receives the report? Who is in the room? Where do we feel unsure or uncomfortable? That moment of discomfort is what you’re aiming for. That’s what needs to be discussed, before the conference, not during when stress-levels are through the roof.
Practice also lets you talk about cultural expectations. How much do you communicate publicly? What feels respectful? Or does that feel like over exposure?
Again, there’s no correct answer here. You need to find the correct answers for your community.
What happens next?
What happens after a decision is often the hardest. Enforcement is almost never a clear case. Sometimes it’s an apology, private or public. Sometimes we need to ask someone to leave the event. It depends on context, and power dynamics.
Not every violation needs the same response. In certain scenarios you may decide to skip a public apology as a resolution, since you’re dealing with someone who has been challenging what’s accepted behavior at previous events, and go straight to removing someone from your event.
What helps is thinking in proportionality. What reduces the chances of this happening again? But also, what helps people feel safe enough to stay in your community? When you decide to give benefit of the doubt and only give a warning, maybe that drives others away from your community, because they do not feel safe anymore.
People move away quietly. I attended a tech event where a show of hands revealed only 5 out of 500 participants identified as female. When I wanted to report poor behavior of a sponsor towards me, the team was overwhelmed, they had no idea what to do. "This has never happened before", they claimed. But I knew there was a reason why there were so few women. I too warn my friends for events that are unsafe, encouraging them to stay away.
Decide in advance the types of decisions you’re willing to make, and what constitutes a serious violation or breach.
In what setting an incident occurred can dictate whether a public response is warranted. An incident between 2 people is different from something that happens on stage.
What's next?
Finally, after the event, take the time to debrief internally. Do a little retro. What went well? Where did you get stuck? This is how your Code of Conduct becomes a living process instead of just a document.
And gosh this is hard, no matter how much thought and effort you put in your policies. Sometimes you’ll escalate issues to another governing body because that’s what your process dictates, but you might not like their handling of an incident.
Especially in smaller communities you’re bound to know one or both sides of an incident, and relationships might be affected. Even more reason to clearly document processes, and think hard about communication.
We can’t possibly attempt to cover all that we’ve learned running Code of Conduct response teams over the years, and we concluded our presentation with some open questions:
- What if you know that a participant (speaker, sponsor, attendee) breached the code of conduct at another event? Do you deny them access to your event? Do you instruct your organizers team to be extra vigilant around this person? What is important to your decision?
- If you have a Code of Conduct team, do you ask the team members to refrain from drinking alcohol for the duration of the event? We do, but it has certainly kept people from volunteering for the position.
Like many things in software and in life, your answer will be a version of “it depends”. We’re curious to hear about your experiences and thoughts, in the comments.
We received the request to share the Code of Conduct training we do, and we will once we cleaned it up!
*_If someone breaks the law, you get the authorities involved. _
Top comments (0)