Contributing#

Start with Code structure for a map of the codebase: what lives where, and how the pieces call into each other.

Architecture A map of the codebase: what lives where, and how the pieces call into each other. Developer guide Set up a training environment, continue training the released model on your own data, and work with datasets, design tasks, metrics, and SLURM launchers. Contributing a metric Move a custom metric you wrote into a tracked file and config entry, and open a pull request.

As you code#

  1. Keep changes focused and use descriptive names.

  2. Add Google style docstrings to public APIs so Sphinx can pull them into the API reference.

  3. Add tests for new behavior and for regressions.

  4. Run the formatter, the linter, and the relevant tests before you request a review.

make format
ruff check src tests
pytest -m "not gpu"

As you commit#

  • Keep each commit to one logical change.

  • Use Conventional Commits, for example docs: explain indexed motif conditioning.

  • Do not commit checkpoints, generated designs, credentials, or local environment files.

As you open a pull request#

  1. Create a short lived branch from main.

  2. Open a draft pull request early when feedback would help.

  3. Explain why the change is needed, how you tested it, and what GPU or data someone needs to reproduce it.

  4. Keep the review surface small, and split unrelated changes apart.

As you review#

Review for scientific correctness, reproducibility, clear configuration behavior, and appropriate tests. Be direct about technical risk, and keep the feedback something the author can act on.

Contributing to the documentation#

We build the documentation with Sphinx and the PyData Sphinx Theme, and host it on GitHub Pages. Write narrative pages in either reStructuredText or Markdown through MyST. Runnable gallery examples live in docs/examples/.

Create the environment without downloading model weights, then install the documentation dependencies. Building documentation does not require a GPU:

bash setup.sh --skip-weights
uv pip install --python .venv/bin/python -r docs/docs_requirements.txt

Build the site from the repository root:

make -C docs html SPHINXBUILD="$PWD/.venv/bin/sphinx-build" SPHINXOPTS="-W --keep-going"

The generated site lands in docs/_build/html/. Treat every Sphinx warning as something to fix before merging, especially broken references and failed autodoc imports.

Documentation structure#

  • docs/quickstart.rst covers install and a first design

  • docs/concepts/ explains how the pieces fit together: the input format, the ways to run the model, and how search and guidance steer it

  • docs/how-to/ holds task-oriented pages with the config overrides and CLI flags for a specific job

  • docs/reference/ holds lookup tables, syntax, and API pages generated from Python docstrings

  • docs/examples/ holds runnable tutorial notebooks rendered with nbgallery. Notebooks are committed without outputs (the nbstripout pre-commit hook strips them and CI rejects notebooks that carry any), so run a notebook locally to see its results

  • docs/contributing/ holds this guide, the codebase architecture overview, the developer guide, and the maintainer-only packaging guide (excluded from the built site)

  • docs/_static/ holds logos and theme overrides

Package releases#

See docs/contributing/packaging.md for distribution builds and release validation. It is for maintainers preparing a release, not RFD4-Proteina users, so it is excluded from the built site.