Skip to content

Latest commit

 

History

History
51 lines (26 loc) · 1.88 KB

File metadata and controls

51 lines (26 loc) · 1.88 KB

🎁 Contributions

How to submit changes

  • Pick or open an issue and assign yourself, so that other people know you're already working on it. Pick the correct labels for the PR (usually at least bug or enhancement, as well as one or multiple of the application services).
  • Create a topic branch on top of the integration branch dev to work on the issue. Pick a meaningful branch name, e.g. something like issue/283-rate-limit-login-attempts. Thee the diagram of the branching strategy in use.
  • Work on the branch until the issue is resolved. The usual rules apply: Create atomic commits with meaningful messages, do not include unrelated changes or built artifacts etc.
  • Clean up your branch: Remove unnecessary changes, merge later fixes to previous commits, rebase on top of dev.
  • Once you're done, create a Pull Request into dev and ask one of the maintainers for a review. The title of the PR should summarize the changes and is usually close to the title of the original issue. The description is mainly intended for the reviewer and should help them understand your approach, possible side effects, dependencies on other features etc.
  • The project maintainers are responsible for merging the integration branch into main.

Note: Other rules may apply if you're working on the project as part of a student project/thesis. Ask your instructor/supervisor.

How to report a bug

:TODO:

How to request an enhancement

:TODO:

📦 Releases

The project uses SemVer for stable releases. The release process is triggered by pushing a valid tag (e.g. v1.2.3) to main.

Note: Stable releases are not deployed to production.

🧑 Maintainers

  • @shoebjoarder
  • :TODO:
  • @ralf-berger (CI/CD)

✏️ Conventions and style guides

:TODO:

🤝 Code of Conduct

:TODO:

🧑‍💼 License

MIT