Result of the Code of Conduct BOF at Debconf
As announced, today there was a bof on a code of conduct. During this
bof, we discussed a draft that I'd written, and some updates were made.
We didn't manage to handle the entire document (time ran out fairly
quickly), but I think what we have now is quite nice -- even if there's
still quite some work to be done.
The video isn't up yet as of this writing, but I'm sure it will be soon.
In the mean time, here's the current working draft:
To me, the goals of a Debian code of conduct should be:
- To improve collaboration by encouraging a positive atmosphere
- To discourage unwanted behaviour
- To provide means to the DPL and delegates to take action in cases of
excessive disregard for others
To meet these goals, a code of conduct should be concise (nobody reads a
multi-page code of conduct); it follows that it should not try to
enumerate every type of possible bad behaviour.
It's probably good if we assume good sense from people reading the
coc. It should be open for interpretation, though of course not to the
extent that calling people names (or similar) would be allowed.
I read several other community codes of conduct (CAcert, GNOME, KDE,
Dreamwidth, mozilla, openstack, tizen, ubuntu) before creating this
## Be respectful
In a project the size of Debian, inevitably there will be people with
whom you may disagree, or find it difficult to cooperate. Accept that,
but even so, remain respectful. Disagreement is no excuse for poor
behaviour or personal attacks, and a community in which people feel
threatened is not a healthy community.
## Assume good faith
Debian contributors have a number of ways to reach the shared goal of
toward a [free](http://www.debian.org/intro/free) operating system.
[diversity statement](http://www.debian.org/intro/diversity) welcomes
participation by anyone.</optional>
<optional>Debian contributors come from a variety of languages,
cultures, and backgrounds,
among our other differences (see also our [diversity
It is helpful to keep this in mind and assume your colleagues are
working in good
faith. If in doubt, assume good faith. <???>If *really* in doubt, ask.</???>
## Be collaborative
Debian is a large and complex project; there is always more to learn
within Debian. It's good to ask for help when you need it. Similarly, offers
for help should be seen in the context of our shared goal of improving
When you made something for the benefit of the project, be willing to
explain to others how it works, so that they can build on your work to
make it even better.
## Try to be concise.
Making a conversation larger makes it more difficult to follow. Writing
a long email means people may have to invest large amounts of time to
understand it. When a long explanation is necessary, consider whether a
summary is appropriate. Try to avoid repeating arguments that have
already been brought forward; this rarely serves any useful purpose.
<asheesh positive version (to replace 1st para; 2nd is OK)>
Keeping conversations short makes them easier to follow. Writing a short
email means people can understand the conversation as efficiently as
possible. When a long explanation is necessary, consider adding a
summary. Try to bring new arguments to a conversation so that each
mail adds something unique to the thread, keeping in mind that the
rest of the thread still contains the other messages with arguments
that have already been made.
Keep in mind that what you write once will be read by hundreds of persons.
Go straight to your point. Stay on topic. Don't repeat yourself.
Try to stay on topic, especially in discussions that are already fairly
## Be open
Most ways of communication used within Debian allow for public and
private communication. As per paragraph three of the [social
contract](http://www.debian.org/social_contract), you should preferably
use public methods of communication for Debian-related messages, unless
posting something sensitive.
This applies to messages for help or Debian-related support, too; not
only is a public support request much more likely to result in an answer
to your question, it also makes sure that any inadvertent mistakes made
by people answering your question will be more easily detected and
## In case of problems.
While this code of conduct should be adhered to by participants, we
recognize that sometimes people may have a bad day, or be unaware of
some of the rules in this code of conduct. When that happens, you may
reply to them and point out this code of conduct. Such messages may be
in public or in private, whatever is most appropriate. However,
regardless of whether the message is public or not, it should still
adhere to the relevant parts of this code of conduct; in particular, it
should not be abusive or disrespectful. Assume good faith; it is more
likely that participants are unaware of their bad behaviour than that
they intentionally try to degrade the quality of the discussion.
Repeated offenders may be temporarily or permanently banned from
communicating through Debian's systems, at the medium's administrator's
# Medium-specific codes
This section contains some guidelines that are specific to one
particular communication medium. Note that the above general guidelines
still apply to each and every one of these medium-specific guidelines,
Email is an important part of Debian; much of our communication happens
through mail. This section applies to all email communication within
Debian, whether on our [mailinglists](http://lists.debian.org/), the [bug
tracking system](http://bugs.debian.org/), or private email between
project collaborators in the context of their Debian work.
- Please use the most appropriate list you can see. If you are unsure,
use debian-user for support-related questions, or debian-mentors for
development-related questions. Be prepared to ask your question on a
different list if told to do so, and mention that it is a resent
- Use the correct language when sending mails to our lists. This is
usually English, unless otherwise noted in the description of the
mailing list in question.
- You should check whether to reply to the List-Post address only, or
whether the original author would like to be a Cc recipient. This may
be indicated in the non-standard Mail-Followup-To header.
- If you wish to be part of a discussion, you should preferably
subscribe to the relevant mailing list, even if only temporarily. If
you choose not to, you should remember that you may lose out on part
of the discussion, even if you explicitly asked to be copied on
- You should avoid sending large attachments (except, perhaps, in
private mail); this generates a lot of unnecessary bandwidth on our
servers. Instead, put the file you would like to attach online
somewhere and post a link.
- Please ensure that your mail system never sends automatic replies to
the list or the BTS. If you do, our system administrators may remove
you from the list or block you from posting to the BTS with immediate
effect to avoid flooding or annoying participants. This ban may be
lifted once the automatic messages have been disabled.
- Replies to a post on a mailing list should, in general, go to the same
mailing list. Do not change the mailing list, unless you are posting
something that is no longer relevant to the original discussion and
clearly off-topic for the mailing list where it is being discussed.
Debian provides interactive chat through the [OFTC](http://www.oftc.net)
IRC network. This section applies to communication through Debian's
official channels (those beginning with #debian).
Do not assume there's someone on the channel at all times. IRC is an
interactive medium; this means that people need to be online and on
the channel to see your question. If you receive no immediate answer
to your question and there is no apparent activity on the channel,
wait a while; people may see it later and reply. You could also come
back later and try again; alternatively, try using one of our
Debian provides the [Planet Debian](http://planet.debian.org/) blog
aggregator service for contributors. While it is not required that blog
posts that are syndicated on Planet Debian have Debian-related content
only, people who often post material that is not related to Debian may
consider only syndicating a Debian-related feed to Planet Debian.
# Further reading
The links in this section do not refer to documents that are part of
this code of conduct, nor are they authoritative within Debian. However,
they do contain useful information on how to conduct oneself on our
- The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/)
by Enrico Zini contain some advice on how to communicate effectively.
- <link to documentation on what to do in case of technical problems>
A few notes on this draft (which already fails the "be concise"
requirement of the very code it's trying to propose):
First, as said, we ran out of time during the bof; the first four points
("be respectful", "assume good faith", "be collaborative", and "try to
be concise") were discussed at length during the bof, even if in some of
the cases here we hadn't yet managed to come up with a final wording
that everyone was happy with. The "In case of problems" section was
dicussed during the bof, but we couldn't finish reviewing it properly.
If you weren't there and haven't watched the video, it could be a good
idea to do that as soon as it's available. Never the less, comments are
certainly still welcome.
Some people walked up to me after the BOF and gave me a few more
opinions on the current draft; these were, mainly, Ian Jackson, Matthias
Klose, and Enrico Zini. While I don't feel comfortable updating a draft
that was edited collaboratively with a full room of people based on
interpersonal discussions, I do think they raised valid points:
- Ian noted that perhaps the "In case of problems" section shouldn't
suggest what to do in case of minor problems, instead assuming that
normal social interaction will play its part there, and that serious
problems will be dealt with by using a formal complaint mechanism that
should perhaps be in the Code of Conduct. While he had some detailed
suggestion on that, I'll let him make his argument.
- Matthias suggested that the medium-specific sections should perhaps
each be in a separate document to which we link in the "Further
reading" section. While I think that might work (and something along
those lines had originally been part of my plan), we should at any
rate make sure that the link to such (normative) sections are
separated in some way from the proposed links to the (non-normative)
community guidelines and technical problems thing that are there
- Enrico suggested that the document should be positive; that getting
"slapped in the face" with a document that tells you what not to do
might be a bad way to go forward.
I believe that, in combination with the changes that Ian suggested
(to only list a formal complained mechanism in the code of conduct)
would alleviate this concern, as people would not be encouraged to
slap others with the code of conduct. Enrico also raised a number of
other points, but I'm afraid I'll have to say that I forgot much of
it; I'll have to ask him to raise them again on the list.
On a more personal note, I'm not entirely sure anymore that adding
medium-specific codes of conduct is a good idea; perhaps the best way
forward is to remove them entirely. At any rate, if we're not going to
remove them, they will need to be fleshed out a bit more.
So that's that. I'm aware that the above proposal isn't anywhere near
perfect yet, and I'm certainly open to more suggestions; any code of
conduct we might or might not accept should be a code that would be
acceptable to the majority of the project. So, please, read it and
comment; hopefully we'll come up with a code that everyone can feel
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.