Conventions

The rules every change follows, from the first commit to the release. How to write a doc is in Writing Docs.

  • Before pushing, run the checks.
  • Branches and pull requests are in Branches and Releases.
  • Workflows pin every action to a commit hash, with the tag in a comment. Jobs that run third-party actions get no secrets and persist-credentials: false. Signing and publishing are separate jobs that use only actions/*.
  • Docs follow Writing Docs.
  • No ids. Docs, the website, help text and code comments say what a thing is, never a letter-number id (A1, Z9) for it.
  • Docs describe what exists today. They have no "yet", "later" or "Where it goes", and no roadmap. The one exception is the waitlist page (link-web/docs/en/waitlist.md), which says plainly that what it offers isn't built. A known gap is stated as a fact. What's built is in the docs, and why is in their decisions.md.
  • Security and configuration docs change with the code. A change to a limit, an auth check, what is stored or logged, or a setting updates the part's security.md (docs/en/<part>/security.md, or docs/en/security/ for what spans parts) and docs/en/CONFIGURATION.md in the same PR.
  • Logging. The relay logs connections, disconnects and logins. It never logs anything per public request (bodies, headers, paths, visitor addresses) and never tokens or passwords, and Caddy keeps no access log. The terms page (link-web/docs/en/terms.md) promises this, so update it if that changes.
  • Licenses. Link is MIT or Apache-2.0, so new dependencies must be permissively licensed. src/tests/e2e/tests/licenses.rs lists what's accepted, and adding to it is a decision, not a fix.
  • Community files in .github/ only point at their pages: docs/en/CONTRIBUTING.md, docs/en/CODE_OF_CONDUCT.md and docs/en/security/.