Start with the project people will actually join
A code of conduct is a shared agreement about participation, not a promise that disagreements will never happen. For a community podcast, listening circle, oral-history project or collaborative sound piece, it should tell people what to expect before they enter a room, join a call or hand over a recording. Keep it short enough to read at the start of a session and specific enough to help someone make a decision when a situation becomes uncomfortable.
Begin by naming where the code applies. That might include planning meetings, recording sessions, group chats, workshops and public discussions connected to the project. State who it covers: organizers, hosts, guests, volunteers and participants. Then describe the kind of space you want to make in ordinary language, such as one where people can contribute without being mocked, pressured to share a personal story or interrupted repeatedly. Invite contributors to help review the draft; they may notice situations the organizers have missed.
Describe respectful behavior in usable terms
Broad requests to “be nice” leave too much open to interpretation. Ask people to let others finish speaking, use the names and pronouns they provide, offer criticism of ideas rather than personal attacks, and make room for quieter participants. It is also reasonable to say that harassment, threats, discriminatory remarks and repeated unwanted contact are not acceptable. These examples give a facilitator something concrete to refer to without trying to list every possible problem.
Audio projects need an extra expectation: a microphone is not permission to dominate a conversation. Explain how turns will be managed and whether a host may pause or redirect a discussion. If participants disagree, encourage them to address the point being made rather than question someone’s right to speak. Make clear that a person may step away from a session or decline a question without having to justify the choice in front of the group.
Make recording and sharing choices explicit
A code for an audio project should distinguish taking part from agreeing to be recorded or published. Before recording, explain what equipment is on, what the material may be used for and whether the project expects to edit it. Ask for clear permission, and offer a way to participate off mic when practical. Avoid recording private conversations simply because a device is nearby. If the project involves children or sensitive personal experiences, plan additional safeguards before the session rather than improvising them afterward.
Set expectations for handling files as well as voices. Say who can access raw audio, where contributors should send it and whether anyone may post clips or behind-the-scenes photos on personal accounts. If you offer contributors a chance to review how their contributions are used, specify what they can review and when. You may not be able to undo every copy of something already released, so do not promise unlimited removal. Instead, give people a clear contact point for raising a concern before or after publication.
Give people a clear way to raise concerns
A rule is more useful when people know what happens if it is broken. Name a contact person or small team and provide a reporting route that does not require someone to confront the person involved in public. For a small project, consider a backup contact in case the main organizer is part of the concern. Tell people what information is helpful, such as what happened, where it happened and whether they need immediate help with participation. Do not demand a perfect account before you listen.
Outline a modest response process. An organizer might first check on the affected person, then gather relevant accounts, decide on an appropriate step and communicate what can be shared with those involved. Steps could include a reminder, a pause in recording, a change in facilitation or removal from a project activity. Avoid guaranteeing secrecy or a particular outcome. Promise instead to handle concerns carefully, limit sharing to those who need to respond and explain decisions as far as privacy allows.
Keep the code visible and revise it
Put the code where people encounter it before joining, such as an invitation, sign-up message or contributor guide. At the start of a gathering, summarize the points most relevant to that setting: how people take turns, when recording begins and whom to contact with a concern. Make the text easy to read, and give participants a way to ask questions privately. If someone needs an adjustment to take part, discuss what the project can reasonably provide rather than assuming one format works for everyone.
Treat the first version as a working document. After a session, ask whether any expectation was unclear or difficult to follow, then revise the wording while keeping the core standards consistent. A useful final check is to ask a new contributor to read the code: can they tell what behavior is expected, how their voice might be used and what they can do if something goes wrong? If the answers are easy to find, the code is doing its job.
