Contributing code#

After setting up your development environment as described in the Development setup, you are ready to start contributing code to Skchange!

Working on an issue#

When working on an issue, you should create a new branch from the main branch in your local, forked repository. The branch name should be descriptive of the work you are doing, e.g., fix-issue-123 or add-feature-xyz.

When writing git commit messages, we encourage the use of Conventional Commits.

Remember that every commit is checked by pre-commit if setup as described in the Development setup. The same checks are also run as part of the continuous integration (CI) pipeline on GitHub Actions when you push your branch to your forked repository and create a pull request.

To run the test suite locally, run pytest in the terminal or use the built-in testing features of VS Code.

Pull requests#

When you have completed your work on an issue, you create a pull request to the main branch of the Skchange repository. Here are some guidelines to make a pull request:

  • Title:

    • Start your pull request title with a conventional commit tag. This helps us add your contribution to the right section of the changelog. We use the Angular convention. Specifying the scope of the commit is optional.

    • Use a descriptive title starting with an uppercase letter. This text will end up in the changelog, so make sure the text is meaningful to the user. Use single backticks to annotate code snippets. Use active language and do not end your title with punctuation.

    • Example: feat: Add new cost class GammaCost.

  • Description:

    • Link to the issue you are working on.

    • Add any relevant information to the description that you think may help the maintainers review your code.

  • Make sure your branch is up to date with the latest changes from the main branch of the Skchange repository.

  • Make sure all continuous integration checks pass.

After you have opened your pull request, a maintainer will review it and possibly leave some comments. Once all issues are resolved, the maintainer will merge your pull request, and your work will be part of the next Skchange release!

Keep in mind that your work does not have to be perfect right away. If you are stuck or unsure about your solution, feel free to open a draft pull request and ask for help.

Contributing to the documentation#

We highly value properly documented code! Sphinx and numpydoc are used to generate the documentation from the docstrings in the codebase. Please make sure to follow the numpydoc style guide when writing docstrings for new functions, classes, and methods.

Contributions to the user guide are also welcome! Raise an issue if you find something missing or unclear.

To build and check the documentation locally, you first need to install the documentation dependencies:

uv pip install -e .[docs]

Then, you can build the documentation by running make docs.

Note that the documentation is also built as part of the continuous integration pipeline when you push your changes to a branch with an open pull request.

Credits#

This page is heavily inspired by the Polars contributing guide.