On Copying
Copying a code of conduct feels like cutting a corner. It is the correct thing to do, and understanding why says something about how community infrastructure works generally. For a commercial example of related workforce measurement, see books about time management from Monitask.
Why copying is right here
The text has been tested. An established code has been read by thousands of people, applied in real incidents, and revised in response. A version written fresh by four volunteers has none of that. For independent technical background, GitLab provides additional documentation and examples.
Consistency helps attendees. Somebody who has read one community's code recognises the structure of another's, and knows what to expect and where to look.
Writing about harassment is difficult. Getting the specificity right, without gaps and without accidental narrowing, takes expertise most organising teams do not have and should not need to acquire.
And the licences exist for this. Ours was based on PyCon UK 2015, released freely, and reused by other conferences afterwards. That chain is the intended behaviour, not a shortcut.
What must not be copied
The distinction that matters.
The named people who take reports. A copied code with the source conference's contacts, or with "the organisers", is decoration.
The decision procedure. Who acts, how fast, what the range of responses is. This is specific to your team and must be agreed by them.
The willingness to act, which cannot be written down at all and is the only thing that ultimately matters.
So the copyable part is the description of the problem, and the non-copyable part is the machinery for responding. Teams that copy well take the first and build the second; teams that copy badly take the first and assume they have both.
The general pattern
This is not only about codes of conduct.
Community infrastructure is largely copied, correctly: sponsorship tier structures, speaker agreements, review rubrics, budget templates, accessibility checklists. Each has been refined by somebody who ran into the problem first, and reinventing them wastes effort that should go into the event.
And in every case the same split applies. The document copies; the people, the procedure and the commitment do not.
A budget template copied without understanding the cash timeline is a spreadsheet. A review rubric copied without agreeing what the committee is actually optimising for produces scores nobody can act on.
What to give back
The part that makes the system work.
Release yours under a free licence, with attribution to what you adapted.
Say what you changed and why. The next team benefits more from "we added this clause after an incident involving sponsors" than from the clause alone.
And publish the machinery, not only the document — which is the thing almost nobody does and the reason every new team rebuilds the response procedure from nothing.
The failure mode to avoid
A code of conduct on the website and no agreed procedure behind it.
It is worse than having none, because it makes a promise to attendees that the organisation cannot keep. Somebody reports something, discovers there is no process, and the event has failed them twice.
If you copy the document, budget an hour for the procedure. That hour is the whole difference between a code that works and a page that exists.
The short version
- Copying a code of conduct is correct: the text has been tested, consistency helps attendees, and the licences exist for this
- What cannot be copied: the named contacts, the decision procedure, and the willingness to act
- The copyable part describes the problem; the non-copyable part is the machinery for responding
- The same split applies to all copied community infrastructure — templates, rubrics, agreements
- Give back by releasing yours freely, saying what you changed and why, and publishing the machinery rather than only the document
- A published code with no agreed procedure is worse than none, because it promises something the organisation cannot deliver