Skip to content

Contributing to drf-partial-response-fields

Thank you for considering a contribution. This document explains how to set up your environment, the standards your change must meet, and how the review process works.

Code of Conduct

This project follows the Code of Conduct. By participating, you agree to uphold it.

Development Setup

git clone https://github.com/mahmoudgshaker/drf-partial-response-fields.git
cd drf-partial-response-fields
python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pre-commit install

Running the Test Suite

pytest

Run the full compatibility matrix (all supported Python and Django versions) with tox:

tox

Run a single environment:

tox -e py312-django50

Code Quality Gates

Every pull request must pass:

  • ruff - linting (ruff check .)
  • black - formatting (black --check .)
  • mypy --strict - static typing (mypy src)
  • pytest - full test suite with coverage
  • pre-commit - all configured hooks (pre-commit run --all-files)

These all run automatically in CI, but running them locally first saves review round-trips.

Making a Change

  1. Open an issue first for anything beyond a trivial fix, so the approach can be discussed before you invest time.
  2. Fork the repository and create a branch from main: git checkout -b feat/short-description.
  3. Write tests for your change. Untested code will not be merged.
  4. Update documentation in docs/ and CHANGELOG.md under [Unreleased].
  5. Ensure all quality gates above pass locally.
  6. Open a pull request describing why the change is needed, not just what it does.

Commit Messages

Use Conventional Commits:

  • feat: add support for X
  • fix: correct Y under Z condition
  • docs: clarify W
  • test: add coverage for V
  • chore: update U

Public API Changes

This package follows Semantic Versioning. Any change to a public class, function, or setting documented in docs/api-reference.md is a breaking change unless purely additive, and requires a major version bump and a migration note in CHANGELOG.md.

Documentation

Documentation lives in docs/ and is built with MkDocs:

pip install -e ".[docs]"
mkdocs serve

Every new public class, method, or setting must be documented in docs/api-reference.md and, where relevant, illustrated in docs/examples.md.

Release Process

Releases are cut by the maintainer via the release.yml GitHub Actions workflow, triggered by pushing a vX.Y.Z tag. The workflow builds the sdist and wheel and publishes to PyPI using trusted publishing (no long-lived tokens are stored in the repository).

Getting Help

Open a GitHub Discussion or an issue tagged question.