Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
96 lines (68 loc) · 3.97 KB

CONTRIBUTING.md

File metadata and controls

96 lines (68 loc) · 3.97 KB
Raw

Contributing to BAUER GROUP projects

Thanks for your interest in contributing. These guidelines apply organization-wide and are inherited by every repository under github.com/bauer-group that does not provide its own CONTRIBUTING.md. Individual repositories may add project-specific rules in their README or their own contributing guide — those take precedence.

By participating, you agree to abide by our Code of Conduct.

Ways to contribute

  • Report bugs and request features via the repository's issue templates.
  • Improve documentation — fixes to READMEs, examples and docs are always welcome.
  • Submit code via pull requests (see the workflow below).
  • Report security issues privately — never in a public issue. See our Security Policy.

Before you start

  • Search first. Check existing issues and PRs to avoid duplicates.
  • Discuss larger changes. For anything beyond a small fix, open an issue first so we can agree on the approach before you invest time.
  • One logical change per PR. Keep pull requests focused and reviewable.

Development workflow

  1. Fork the repository (external contributors) or create a feature branch (members): feat/short-description or fix/short-description.
  2. Make your change. Match the existing code style, naming and structure of the project.
  3. Add tests for new features and regression tests for bug fixes, where the project has a test suite.
  4. Run the project's checks locally before pushing — build, tests and linters must pass. A red build or failing tests means the change is not ready.
  5. Commit using Conventional Commits (see below).
  6. Open a pull request against the default branch and fill in the PR template.

Commit messages — Conventional Commits

We use Conventional Commits to drive automated versioning and changelogs. Commit messages are written in English.

<type>(<scope>): <subject>

<body explaining what changed and why>

<footer: BREAKING CHANGE / issue references>

Common types: feat (new feature, MINOR), fix (bug fix, PATCH), perf, refactor, docs, style, test, chore, build, ci, revert. A ! after the type or a BREAKING CHANGE: footer signals a breaking change (MAJOR).

Subject: concise, imperative or past-tense per the project's convention, no trailing period, aim for ≤ 50 characters (hard limit 72). Keep proper nouns and acronyms in their canonical case (OAuth, JSON, iOS, WebSocket).

Body: for non-trivial changes, explain what and why — not the diff itself.

Example:

feat(auth): add Google OAuth provider

Customers requested SSO for B2B onboarding. The OAuth flow
uses authorization-code + PKCE; provider config lives in
environment variables, never in code.

Closes #123

Pull request expectations

  • Reference related issues (Closes #123).
  • Keep the diff focused; split unrelated changes into separate PRs.
  • Ensure CI is green — we do not merge on a red pipeline.
  • Update documentation and changelog entries where relevant.
  • Be responsive to review feedback; we aim to review promptly in return.

Coding standards (baseline)

  • Security first — never commit secrets, credentials or API keys; use environment variables or a secret manager. Validate, sanitize and escape all external input. Follow the OWASP Top 10.
  • No PII or secrets in logs.
  • Readable over clever — clear names, early returns, single responsibility.
  • No AI attribution in commits (no Co-Authored-By trailers for AI tooling).

Licensing of contributions

Unless a repository states otherwise, contributions are accepted under the repository's license (see its LICENSE file). By submitting a contribution you confirm you have the right to do so and that it may be distributed under that license.

Questions about contributing? See SUPPORT.md.