Code of conduct

This code protects two groups from two dangers. It protects users — including the non-technical, the non-English-speaking, the beginner who wandered in — from being treated as failed programmers. And it protects the people who do the work from the pressure of a crowd that outnumbers them a thousand to one. Most codes of conduct only look in one direction; this one refuses to choose, because the project has seen what each direction costs.

What this code does not govern

Technical disagreement is not a conduct problem, and this code will never be used to make it one. Criticism of the project — its design, its decisions, its code, its priorities — is never sanctioned as conduct, however sharp, however inconvenient, and whoever it targets. Only the way people treat people is in scope here.

The line between the two is not the temperature of a message, and it is not in the eye of the beholder: it is the object of the statement, and it can be checked on the words themselves. A statement about the work — the code, the decision, the design, the record — can be answered with evidence: fix the code, produce the record, concede the point. A statement about the person — their nature, their worth, their motives, their right to be here — cannot be answered by anything except defending one’s character, and that is precisely why it has no place in a working discussion. The test: if improving the work or producing the record could answer the sentence, it is criticism, and it is protected; if only defending oneself could, it is an attack, and it is moderated. Nobody’s feeling of having been treated with contempt, and nobody’s feeling of having stayed polite, changes what a sentence is about.

Three consequences, stated bluntly:

• Anger aimed at the work is testimony, not a violation. “This release broke a promise and I am furious” is a statement about the work, however hot. This code will not be the instrument by which the substance of a critique is dodged by prosecuting its form.
• Correcting a person is protected; dismissing one is not. “It can’t be that hard, just add an option” is a claim about the work — and so is its refutation. Telling someone their picture of the internals is false, bluntly and with the reasons, engages the claim and is protected, however unwelcome: if you assert how the software works, you have made a technical claim, and you own what happens to technical claims here — they get answered with the record. What fails the test is the dismissal that replaces the correction: “you clearly don’t understand how software works”, full stop, engages nothing and targets only the person. The same words followed by the actual explanation are an answer; alone, they are an exit. And the polite version — the condescension that explains nothing — fails the same way, only more slowly.
• A mixed message gets two treatments. A correct diagnosis wrapped in a jab is two statements: the jab is moderated, the diagnosis is answered. Neither cancels the other — moderating the form never discharges the duty to answer the substance, and being right about the work never licenses the statement about the person.

The rules

1. Write in whatever language you can. Broken English is fine; so is not using English at all. Moderation is guaranteed in English and French, best-effort in German, and by machine translation elsewhere — say so if a translation misreads you.
2. Nobody is blamed for not knowing computers. A user who cannot follow a technical instruction has found a documentation or design problem, not committed a personal failing. Trade knowledge is different: Ansel expects its users to learn the craft (scope), so answering a photography or color question by naming the right documentation chapter is help, not dismissal. What makes the difference is the gesture: “see the chapter on X” teaches; “read the manual”, unadorned, dismisses — and silence with a label dismisses twice.
3. Other software may be discussed freely. Comparing Ansel to any editor, commercial or free, is legitimate and often the fastest way to describe a problem. Nobody is an outsider here for the tools they also use, and no censorship will be exerted on discussions presenting or promoting other applications, even seen as competitors.
4. Discussion exists to reach decisions. State the problem, add information, converge. Chitchat, “me too” and thanks-without-content belong in chat channels — not because warmth is unwelcome, but because threads are the project’s memory and search index. Too much communication is harmful too and leads to information fatigue.
5. One thread, one topic. For the reader who comes after you, and for the search engine that will serve them.
6. Define problems by the goal, not by the fix. “I want my picture to look more X” can be worked with; “add a button that does Y” cannot (why).
7. No attacks on persons. What someone is — their identity, their competence as a person, their presumed motives — is never the subject. A contribution can be wrong; make the case on the contribution.
8. No sieges. One clear report is enough. Repetition, pile-ons, deadlines set for volunteers, and the polite-but-endless demand for justification that stops only when its target breaks — these are pressure tactics, and they are treated as such regardless of how courteous each individual message looks.

How criticism is sorted

Every hard conversation here falls into one of three cases, and each has its treatment. The distinction is made on statements, never on the person making them — the same person may produce all three in a week:

• An attack on a person is moderated (rule 7) — whoever makes it, whoever it targets.
• A demand outside the project’s scope is refused by quoting the scope — it is a legitimate wish, legitimately declined, and declining it is not a conduct issue in either direction. No tool can pretend to support all possible use cases and all categories of users without becoming a liability to its maintainers and to its users as well. Making choices and sorting priorities is part of good design in a World of finite resources.
• A critique that holds the project to its own commitments — you promised this, the record shows that — is the most valuable input this project receives. It is answered on substance or conceded; it is never moderated, and never reclassified as “toxicity” because it was insistent or angry.

The same rules for everyone

A behaviour keeps its name whatever the position of the person who shows it. The maintainer’s frustration is subject to rule 7 exactly as a newcomer’s is; seniority buys authority over code, never immunity for conduct. If you believe moderation has been applied asymmetrically, say so publicly and cite this section: the claim will be answered with the record, not with a lock.

Patterns count

These rules judge statements, not people — at the scale of a single exchange. Over a long series, the record itself becomes the subject: someone who, for months, never acknowledges an error, never absorbs an answer, and returns the same demand regardless of what was explained is no longer having a conversation, and naming that pattern — with dated references — is a legitimate synthesis, not an attack. The same holds for us: if the project repeatedly fails its own engagements, the dated record of it is fair argument, and the pact exists to be quoted.

Enforcement and appeal

Sanctions are graduated, and each step is notified with its reason: first a public reference to the rule broken; then hiding or locking the specific content; then a temporary block; then, for sustained abuse only, a ban. Sanctions target behaviours, are as bounded in time as the tools allow, and every one of them can be appealed. Appeals are addressed to the current maintainers of the project — reply to the moderation notification, or open a thread in Discussions  referencing this code; if the sanction itself blocks you from the venue, use the contact channel the repository  publishes. Where more than one maintainer exists, the appeal is examined by someone who did not take the original decision. The answer will address your arguments, not your worthiness. Moderation acts are public wherever the platform permits: an unexplained disappearance is a moderation failure, not a moderation style.

Venues: this code applies on the GitHub repository  (issues, pull requests, discussions), the Matrix channels, and any official space the project opens. The canonical text lives on this page; the repository links here.