Skip to content

Contributing to the App

The project is packaged with a light development environment based on docker-compose to help with the local development of the project and to run tests.

The project is following Network to Code software development guidelines and is leveraging the following:

  • Python linting and formatting: black, pylint, bandit, flake8, and ruff.
  • YAML linting is done with yamllint.
  • Django unit test to ensure the app is working properly.

Documentation is built using mkdocs. The Docker based development environment automatically starts a container hosting a live version of the documentation website on http://localhost:8001 that auto-refreshes when you make any changes to your local files.

Creating Changelog Fragments

All pull requests to next or develop must include a changelog fragment file in the ./changes directory. To create a fragment, use your GitHub issue number and fragment type as the filename. For example, 2362.added. Valid fragment types are added, changed, deprecated, fixed, removed, and security. The change summary is added to the file in plain text. Change summaries should be complete sentences, starting with a capital letter and ending with a period, and be in past tense. Each line of the change fragment will generate a single change entry in the release notes. Use multiple lines in the same file if your change needs to generate multiple release notes in the same category. If the change needs to create multiple entries in separate categories, create multiple files.

Example

Wrong

changes/1234.fixed
fix critical bug in documentation

Right

changes/1234.fixed
Fixed critical bug in documentation.

Multiple Entry Example

This will generate 2 entries in the fixed category and one entry in the changed category.

changes/1234.fixed
Fixed critical bug in documentation.
Fixed release notes generation.
changes/1234.changed
Changed release notes generation.

Branching Policy

  1. Open an issue
  2. Get approval from one of the codeowners before working on the issue
  3. If working on the issue, assign the issue to yourself
  4. Fork the Project and Create a branch in the fork
  5. Open a PR into develop, from the branch in your fork
  6. Get peer review and approval to merge from one of the codeowners
  7. Once approval has been gained, the PR will be merged into develop
  8. One of the codeowners will enumerate the features added per the contributor's PR when a tagged release is merged into main

Release Policy

Releases are on a somewhat adhoc basis as needed. A more formal release process may be decided upon in the future.