Community guidelines and rules

There are two rules.

1. If your actions interfere with the goals of this project or with the people working on it, they are not allowed.
2. If you do not understand these rules, please turn away.

That is the complete list. Everything below explains why it is that short. None of it is a third rule.

Why there is no catalogue of behaviours

A code of conduct written as an enumeration — a list of named behaviours, each with a matching step in a process — reads to most people as thoroughness. To a small number of people it reads as a specification. It tells them exactly how far they may go, and it hands them their defence in advance: what I did wasn't on the list.

It never is on the list. It cannot be. No list written today anticipates what somebody thinks of next year, and a person committed to being a problem is more inventive about it than the person writing the list was. Every clause added is one more edge to stand on.

So this project does not keep a catalogue. Rule 1 is about effect. Whether what you did has a name, whether it has happened here before, whether you can find it written down somewhere — none of that is the question. The question is whether it got in the way of the project or of the people doing the work. “It wasn't listed” is not an answer to that question, because there is no list to be absent from.

What rule 1 asks of you

The project has goals, and it has people spending their own time on them. Rule 1 asks you not to be an obstacle to either.

That is a judgement, made by people, in context, after looking at what actually happened. It is deliberately not a formula and it will not be applied like one. Two people doing superficially similar things can land on opposite sides of it, because what is being weighed is the effect, not the form.

If you are here in good faith you will almost never have to think about this rule at all. That is the normal case, and it covers nearly everyone.

What rule 2 is for

Rule 2 is not a brush-off, and it is not aimed at anyone whose first language isn't English, or who is new to this, or who is unsure how a project like this works. Ask. Someone will explain, and gladly.

It is aimed at the reader who finishes rule 1 and wants to know exactly where the line is, so they can stand as close to it as possible without crossing. That question has no answer here, and wanting it answered precisely is itself the thing being warned about. If taking part requires the boundary surveyed first, this is not the project for you, and it is better for both of us that you learn that now rather than later.

Mistakes

People misjudge things. They phrase something badly, or land a change that costs somebody a week. That is ordinary, and it is not what any of this is about. You get told, you fix it or you apologise, and it ends there.

The difference between a mistake and a problem is what happens after somebody points it out.

Who decides, and what follows

The maintainers decide. There is no committee, no form to file and no tribunal; this is a small project and pretending otherwise would be theatre.

Being asked to stop is not the opening of a negotiation. Where it goes from there depends on what happened and on what you do next: usually nothing further, sometimes a request to drop a subject, and at the far end removal from the project's channels and repositories. That last one is not appealed by re-arguing the rules.

Where this applies

Wherever the project happens: the IRC channel, the code forge, issues and reviews, and any other space carrying the project's name. It also covers conduct elsewhere that is aimed at people here because they are here.

If something is going wrong

Tell a maintainer. On IRC a private message is fine and does not have to happen in the channel. You do not need a case assembled first — “this is bothering me” is enough to start.