Skip to content

Latest commit

 

History

History
107 lines (76 loc) · 4.17 KB

CONTRIBUTING.md

File metadata and controls

107 lines (76 loc) · 4.17 KB

Contributing to APIS

First off, thanks for taking the time to contribute! ❤️

All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉

Table of Contents

I Have a Question

If you want to ask a question, we assume that you have read the available Documentation.

Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open an Issue.
  • Provide as much context as you can about what you're running into.
  • Provide project and platform versions, depending on what seems relevant.

We will then take care of the issue as soon as possible.

Styleguides

Please try to keep your commit changes focused on the change you want to implement - don't start fixing typos if your commit is actually about adding a feature.

We use ruff for linting and code formatting and djlint for formatting templates - the configuration for those is part of our pyproject.toml. We also check the code using the deptry dependency checker for missing or unused dependencies.

Base your commit on the latest changes in main. Your work might take some time and other people are also working on APIS, so please rebase your changes early and often.

Commit Messages

We use conventional commits so please format your commit messages accordingly. There is a GitHub Action that uses the Gitlint linter to check your commit messages for validity.

Please try to use a scope when writing a commit message. APIS consists of various individual modules, so the scope tells the users which module your change refers to.

Examples:

feat(apis_entities): introduce a e53_place autocomplete template

(ac358a7e)

or

fix(apis_relations,apis_entities): replace get_object_or_404

(6785b802)

Feel free to browse our commit history to get an idea how commit messages should look like.

We use the release-please GitHub Action, which uses the information from the conventional commit messages to generate changelogs and bump the version. Therefore it is important to use the correct commit type in the commit message, i.e. fix for smaller fixes, feat for new features. Breaking changes have to have an exclamation mark (!) after the type/scope, but please also explain the breaking change in the commit message body.

An example how a resulting changelog could look like would be the changelog of release 0.26.0. Feel free to browse the releases and the CHANGELOG file.

Workflows

You can see a list of worklows which are run on pull requests here.

Attribution

This guide is loosely based on the contributing-gen. Make your own!