Contributing

Thanks for considering a contribution. A few things to know before you start. This page mirrors CONTRIBUTING.md in the repo root.

Licensing of contributions

RedScribe is source-available under the PolyForm Noncommercial License 1.0.0, paired with a separate commercial license. See What is RedScribe? for what that means. By submitting a pull request, you agree your contribution is licensed under the same terms as the rest of the project. There’s no formal CLA/sign-off process at this stage. That may be introduced before any contribution goes in, so don’t be surprised if a PR gets held for that conversation first.

Getting a dev environment running

The fastest loop is Method 4, local development with no Docker rebuild cycle. See Local development for the full setup and day-to-day loop.

If you touch the Tiptap editor bundle, the password strength meter, or Tailwind classes, rebuild the frontend assets per Frontend asset builds before committing, since the built output in static/vendor//static/css/ is what actually ships.

Running the test suite

python manage.py test

The project has substantial existing test coverage (900+ test methods as of this writing, see Testing). A PR that changes behavior should come with tests covering it, following the existing style in the relevant app’s tests.py.

Before opening a PR

Run the full test suite locally. CI (.github/workflows/test.yml) runs it again on every PR, but catching failures locally first is faster for everyone.
Add a CHANGELOG.md entry under [Unreleased] describing the change, following the existing Keep a Changelog format already used there.
Keep the change scoped. This codebase favors small, well-reasoned diffs with docstrings explaining why a non-obvious decision was made, rather than sweeping refactors bundled with feature work. You’ll see this pattern throughout the existing code: a short comment justifying an unusual choice (an ordering, a fallback, an edge case) rather than restating what the code already says.

Reporting bugs / requesting features

Use the issue templates under .github/ISSUE_TEMPLATE/. They ask for the information that’s actually useful for reproducing a problem in a self-hosted Django app: version, install method, and whether it reproduces on a clean instance.

Reporting a security vulnerability

Do not open a public issue for a security vulnerability in RedScribe itself. Use GitHub’s private vulnerability reporting (repo’s Security tab → Report a vulnerability). See .github/SECURITY.md in the repo for the full policy, including what’s in and out of scope. RedScribe’s own code and default configuration is in scope. How you secure your own deployment, and gaps already listed under CHANGELOG.md’s known limitations, are not.