Code of Conduct

The short version

• Be patient with beginners. They are not an interruption to this project; they are the point of it.
• Assume the other person means well. Most friction online is a badly worded sentence, not an enemy.
• Keep every space fit for a ten-year-old, because one is probably reading.
• Criticise the code, never the person.

Why this page exists

BASIC-256 was built to teach programming to people who have never programmed — often children, often in a classroom with a teacher who is learning alongside them. That gives our community an unusual make-up. The questions asked are frequently basic, sometimes the same one twice in a week, and often written in someone's second or third language.

A project like this fails quietly if its spaces become uncomfortable to ask questions in. Nobody announces that they were made to feel stupid; they simply leave and do not come back. This page exists so that the standard is written down rather than assumed.

Where it applies

Everywhere the project has a presence:

• The GitHub repository — issues, pull requests, discussions, commit messages and code review.
• The Discord server, including direct messages that begin there.
• This website, including anything sent through the contact form.
• Anywhere else you are visibly speaking for BASIC-256 — a conference talk, a forum thread, a social post under the project's name.

It applies to everyone equally: first-time visitors, long-standing contributors, and the maintainers themselves.

What we expect

• Answer the question that was asked. If it has been asked before, link to the answer kindly — "asked and answered" with no link is just a door closing.
• Assume good faith. Read the most reasonable interpretation of a message, not the most annoying one.
• Make room for imperfect English. Many people here are writing in a language they are still learning. Correct code, not grammar.
• Review code, not coders. "This loop runs one time too many" is useful. "Did you even test this?" is not.
• Respect that maintainers are volunteers. Nobody is paid for this. A feature request is a request, a bug report is a gift, and neither comes with a deadline.
• Take a breath before replying angrily. Nothing here is urgent enough to be worth it.

What is not acceptable

None of the following is welcome anywhere in the project:

• Harassment of any kind, including following someone between channels to continue an argument they have walked away from.
• Sexual language, imagery or advances. There are children in these spaces. This is not a matter of taste and there is no context in which it is fine here.
• Slurs or demeaning remarks about age, disability, ethnicity, sex, gender identity or expression, nationality, appearance, race, religion, or sexual orientation.
• Personal attacks and insults, including the ones dressed up as jokes or as blunt honesty.
• Publishing private information — someone's address, workplace, school, real name or photographs — without their clear permission.
• Threats of any kind, whether or not you mean them.
• Deliberate disruption: derailing threads, arguing in bad faith to waste people's time, or repeatedly reopening a settled decision.
• Spam and off-topic promotion, including using the project's spaces to advertise your own.
• Encouraging anyone else to do any of the above.

A word about the youngest users

Teachers use BASIC-256 with classes, and children turn up in our spaces on their own. Adults in the community are expected to behave accordingly: keep conversations public where you can, do not seek out private contact with someone you know to be a child, and do not ask any user for personal details they have no reason to give.

If you are a parent, guardian or teacher and something in one of our spaces concerns you, tell us. We would far rather hear about it early.

If something goes wrong

Report it through the contact form. It goes privately to the maintainers and not into any public thread.

Useful things to include, as far as you have them: where it happened, roughly when, who was involved, and a link or screenshot. A report without all of that is still worth sending — we would rather have an incomplete report than none.

What you can expect: we will acknowledge it, we will keep who reported it to ourselves, and we will not tell you to go and work it out with the other person yourself. Reporting something in good faith will never count against you, even if we end up concluding that no rule was broken.

What happens next

Maintainers decide what a situation needs. Depending on what happened and whether it has happened before, that may be:

• A quiet private word, which is how most of it ends.
• Editing or removing the offending comment, commit message or file.
• A formal warning, with a clear description of what has to change.
• A temporary suspension from one or all of the project's spaces.
• A permanent ban, for serious cases or for repeating behaviour after a warning.

We aim to act proportionately and to explain our reasoning to the people directly involved. We will not conduct enforcement as a public spectacle, and we are not obliged to debate an outcome with onlookers.

If you believe a decision about you was wrong, say so through the contact form. It will be read by a maintainer and reconsidered honestly.

What maintainers owe you in return

The people running the project hold themselves to this document too, and to a little more besides: to apply it consistently rather than according to who is involved, to act on reports rather than let them go quiet, and never to use enforcement to win a technical argument. A maintainer who cannot do that should not be moderating that conversation.

About this text

This code of conduct is written for BASIC-256 rather than adopted wholesale from elsewhere, though it shares its intent — and a good deal of hard-won wisdom — with the Contributor Covenant, which is the standard many open-source projects use and is worth reading in its own right.

Suggestions for improving it are welcome in GitHub Discussions, like any other part of the project.