docs: add CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,116 @@
+# Contributing to Bento
+
+Thanks for your interest in contributing to **Bento**, a genomics data orchestration service developed by the [Canadian Centre for Computational Genomics](https://computationalgenomics.ca/).
+
+Bento is a collection of microservices distributed across multiple sub-repositories. Most contribution workflows are similar across repos, but some details (setup, tests, linting) live in each sub-repo's own `README`. This document covers the conventions that apply platform-wide.
+
+## Code of Conduct
+
+This project and everyone participating in it is expected to abide by a code of conduct. We follow the [Contributor Covenant](https://www.contributor-covenant.org/version/2/1/code_of_conduct/). By participating, you agree to uphold its terms. Report unacceptable behavior to the maintainers.
+
+## Getting Started
+
+### Setup
+
+Setup instructions live in each repository's `README.md`. Start there for environment configuration, dependencies, and how to run the service locally.
+
+For the main Bento distribution, see the [development docs](https://github.com/bento-platform/bento/blob/main/docs/development.md).
+
+### Running tests and linters
+
+Each sub-repository defines its own testing and linting setup. Check the relevant `README.md` and the GitHub Actions workflows in `.github/workflows/` to see exactly which commands are run in CI — your local checks should match those.
+
+## Finding Something to Work On
+
+Internal contributors track work in **Redmine**. Before starting on something:
+
+1. Find or create a ticket in Redmine that describes the work.
+2. Assign the ticket to yourself.
+3. Keep the status up to date (e.g., *In Progress*, *In Review*, *Closed*) as you progress.
+
+This keeps the team aware of who is working on what and avoids duplicated effort.
+
+## Making Changes
+
+### Branch naming
+
+Use descriptive, prefixed branch names. Recommended conventions:
+
+- `feature/<short-description>` — new functionality
+- `fix/<short-description>` — bug fixes
+- `chore/<short-description>` — tooling, refactors, dependency bumps
+- `docs/<short-description>` — documentation-only changes
+
+Including the Redmine ticket ID is encouraged, e.g. `feature/1234-add-search-endpoint`.
+
+### Commits
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/). Each commit message should look like:
+
+```
+<type>(<optional scope>): <short description>
+
+<optional body>
+
+<optional footer>
+```
+
+Common types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `build`, `ci`, `perf`.
+
+Examples:
+
+```
+feat(katsu): add phenopacket v2 ingest endpoint
+fix(gohan): handle empty VCF gracefully
+docs: clarify bentoctl installation steps
+```
+
+### Code style
+
+Each sub-repository specifies its own formatter and linter. Use the tool configured in that repo, and check the repo's GitHub Actions lint workflow to ensure your changes pass the same checks CI will run. If a pre-commit hook or formatter config (e.g., `pyproject.toml`, `.eslintrc`, `.prettierrc`) is present, use it.
+
+## Pull Requests
+
+### Opening a PR
+
+- Open the PR against the appropriate base branch (usually `main` unless otherwise noted).
+- Use a clear, conventional-commit-style title (e.g., `feat(service): add X`).
+- In the description, include:
+  - A short summary of the change and why it's needed.
+  - A link to the relevant Redmine ticket.
+  - Notes on anything reviewers should pay extra attention to (migrations, breaking changes, config updates).
+  - Testing notes — what you ran and what you observed.
+- Keep PRs focused. Smaller, single-purpose PRs are easier to review and merge.
+
+### Reviews
+
+Pick reviewers based on context:
+
+- Anyone who has recently worked on or owns the affected area of the codebase.
+- Anyone else whose input you think is relevant (domain knowledge, dependent service owners, etc.).
+
+At least one approval is required before merging. For larger or cross-cutting changes, get an additional reviewer.
+
+### CI and merging
+
+- All CI checks (tests, linters, builds) **must pass** before a PR can be merged.
+- Address review comments before re-requesting review.
+- **Squash and merge** is the default merge strategy, so that the main branch keeps a clean, conventional-commits history. Use a regular merge commit only when individual commits are meaningful and should be preserved.
+
+## Reporting Bugs and Security Issues
+
+To report a bug or security issue, please use this form:
+
+👉 [Bug/security report form](https://forms.gle/gtihcUDUpa64b14R6)
+
+For security issues, please **do not** open a public GitHub issue. The form is the right channel — it lets us triage and respond privately before any disclosure.
+
+## Licensing of Contributions
+
+Bento is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE). By submitting a contribution, you agree that your contribution will be licensed under the same LGPL-3.0 terms.
+
+If you are contributing on behalf of an organization, make sure you have the authority to do so.
+
+---
+
+Thanks for helping make Bento better! 🎉