Contribute

Useful contributions usually start with somebody hitting something of their own. A page behaved unexpectedly; a setting did not do what the manual implied; a sentence in the documentation turned out to mean two things; a step assumed access you did not have. Those are the raw material a better project is made of, and describing one clearly is a contribution in its own right.

You do not have to fix anything to help. A precise account of what you expected, what happened instead, and which document you were following is often more valuable than a patch, because it tells whoever maintains that part what the work actually is.

A contribution is an offer, and the people who maintain the project decide what to accept. A change may be taken as it is, adjusted, held for later, or declined — because it does not fit what the project is for, because it would move a boundary that was drawn deliberately, because it is not correct, or simply because nobody has had time to review it yet.

What that does not affect is your own copy. The licence already gives you the right to change the software for yourself and to distribute your own version, and you do not need approval from anyone to do it. Contributing an improvement back is what makes it useful to everyone else — which is why people do it, and why nobody is obliged to.

Most faults are found by the people using the software, and most reports that are fixed quickly share the same few qualities. They are worth spelling out — not because the project demands a form, but because a clearer report is a shorter path to a fix.

Say what you expected and what happened instead. The gap between the two is the fault. "The language switcher stayed on English after I changed the locale" describes something; "the site is broken" does not.

Say where you are. The Foundation release the site runs, the page or route involved, and the language, if the problem is language-specific. A fault that appears in one language and not another is a different fault from one that appears everywhere.

Say what you changed. Whether the site is a fresh Foundation project or a customised one matters: a fault in the platform and a fault in a site built on it are different pieces of work, and both are worth reporting.

Quote the message exactly. The precise wording of an error is often the fastest route to its cause, and a paraphrase loses the part that identifies it.

Say what you already tried. It saves somebody repeating work you have done, and it sometimes shows that the documentation led you somewhere it should not have — which is a documentation fault in its own right.

If you want to contribute technical work rather than report something, the repository states the project's own expectations, and it is worth reading before you spend time on a change. The operating rules for coding agents, the architecture document and the validation manual together describe how the codebase is built, what a change is expected to include, and what the gate proves — including the project's rule that a capability may not be claimed above the level its implementation and tests actually verify.

Those documents are the project's maintenance discipline rather than a community charter. They describe how this codebase is kept coherent, and they are also honest about capacity: a small number of maintainers review what arrives, and a change that comes with its own tests, a clear description of the problem it solves, and no unrelated edits is far more likely to be taken than one that leaves the work of understanding it to somebody else.