Contributing¶

Thanks for wanting to contribute to MTPPy2.0! This file describes the workflow.

Before you start¶

• Read the Code of Conduct
• Have a look at docs/developer where many details are explained
• Check open issues to see if your topic already exists
• For larger changes: open an issue first and align on the approach

Setting up your dev environment¶

Please refer to Repo-Setup to get started. Continue with Repo-Initialization to get started.

Branching model¶

• main is the last released version
  • Merge target when new release created by Maintainer
  • Protected against direct push
  • Merge requires Maintainer status
  • Merge requires successful pipeline completion
  • Python package is released from here
  • Only branch to create Tags for release
• develop is our default integration branch
  • Contributor's target for merge requests
  • Protected against direct push
  • Merge requires Maintainer status
  • Merge requires successful pipeline completion
• Feature branch: feature/<short-description>
  • Contributor's choice for new features
• Bugfix branch: fix/<short-description>
  • Contributor's choice to provide a bugfix
• Documentation branch: docs/<short-description>
  • Contributor's choice to update documentation
• Experimental branch: experimental/<short-description>
  • Contributor's choice to try out a new idea
• Hotfix branch: hotfix/<short-description>
  • Special branch for production relevant urgent fixes
  • Only branches to be merged into main directly
  • Contributor's choice to provide a hotfix for main
  • In case of merged into main directly, develop will be rebased onto main to receive the same hotfix
• Release branch: release/<short-description>
  • Created by Maintainer during release process
  • Short-lived branch to create a release

Commit conventions¶

We use Conventional Commits:

feature: add new feature X
fix: resolve bug Y in module Z
docs: update README
experimental: try out something
hotfix: resolve bug Y in module Z for main branch

Pull and Merge process¶

1. Fork the repo or create a feature branch from develop
2. Make your changes, including tests
   Note: Without tests, Maintainer may refuse to merge changes
3. Add an entry to CHANGELOG.md under "[next_release]"
   Note: If there is no such label yet, you are probably the first one introducing something new after last release
4. Open a Merge Request with a description and a link to the related issue (template loads automatically)
5. Checkout successful completion of automatic pipeline
6. Wait for at least one review from a maintainer (see CODEOWNERS)
7. After approval: a maintainer will squash-merge into develop

Coding standards¶

• Run the linter/formatter before committing
• Add tests for new functionality
• Document public functions
• Update Changelog
• Check the correct build of documentation via
  

  uv run zensical build
  

Becoming a maintainer¶

See GOVERNANCE.md.