From 3c86413501e08d75c70edc07c971fae45bb41389 Mon Sep 17 00:00:00 2001 From: Copilot <198982749+Copilot@users.noreply.github.com> Date: Sun, 5 Apr 2026 19:47:05 +0100 Subject: [PATCH] docs: add contribution guide to mkdocs site (#85) --- docs/contributing.md | 202 +++++++++++++++++++++++++++++++++++++++++++ mkdocs.yml | 1 + 2 files changed, 203 insertions(+) create mode 100644 docs/contributing.md diff --git a/docs/contributing.md b/docs/contributing.md new file mode 100644 index 0000000..54d3aef --- /dev/null +++ b/docs/contributing.md @@ -0,0 +1,202 @@ +# Contribution Guide + +Contributions to PyTrendy are welcome! This guide covers the standards and processes we follow to keep the project consistent and easy to collaborate on. + +--- + +## Getting Started + +1. **Fork** the repository on GitHub. +2. **Clone** your fork locally: + ```bash + git clone https://github.com//pytrendy.git + cd pytrendy + ``` +3. **Install development dependencies:** + ```bash + pip install -e ".[dev]" + ``` + The `dev` group installs everything needed to run the project and its test suite — the core dependencies (`numpy`, `pandas`, `scipy`, `matplotlib`) are pulled in automatically, and `dev` adds `pytest`, `pytest-cov`, `pytest-mpl`, and `pytest-timeout` on top. + + If your PR touches documentation, also install the docs group: + ```bash + pip install -e ".[dev,docs]" + ``` + +--- + +## Roadmap & Issues + +The project roadmap lives in **[GitHub Issues](https://github.com/RussellSB/pytrendy/issues)**. Browse open issues to find tasks to pick up, report bugs, or propose improvements. + +Before starting work, check whether a relevant issue already exists. If it does, comment on it to signal you are working on it. If it doesn't, open a new issue first so the approach can be discussed before code is written. + +### Issue Title Conventions + +Issue titles follow a `[Tag] Short description` format: + +| Tag | Description | +|---|---| +| `[Bug]` | Something is broken or behaving incorrectly | +| `[Docs]` | Documentation additions or improvements | +| `[Enhancement]` | Improvement to an existing feature | +| `[Feature]` | A new capability or feature | +| `[CI]` | Changes to CI/CD pipelines or automation | +| `[Maintenance]` | Refactoring, tooling, dependency updates | + +### Labels + +Issues are tagged with one or more labels for filtering: + +| Label | Meaning | +|---|---| +| `bug` | Confirmed bug | +| `documentation` | Relates to docs | +| `enhancement` | Improvement to existing behaviour | +| `feature` | New functionality | +| `test` | Requires test coverage | +| `maintenance` | Tooling, CI, or refactoring work | +| `good first issue` | A good starting point for new contributors | +| `priority` | Needs to be resolved soon | + +--- + +## Branching + +All work should branch off `develop`, **not** `main`. The `main` branch is reserved for stable releases. + +```bash +git fetch origin develop +git checkout -b my-feature origin/develop +``` + +Branch names should be short and descriptive, e.g. `fix/trend-detection-edge-case` or `docs/add-contribution-guide`. + +--- + +## Commit Messages + +This project uses the [Conventional Commits](https://www.conventionalcommits.org/) specification. Following this format is important because the project uses **semantic-release** to automate versioning and changelog generation — the commit type determines what version bump is applied on release: + +- `feat` → minor bump (0.**x**.0) +- `fix` → patch bump (0.0.**x**) +- breaking change (with `!` or `BREAKING CHANGE:` in footer) → major bump (**x**.0.0) +- All other types (`docs`, `ci`, `chore`, etc.) → no version bump + +All commit messages **must** follow this format: + +``` +(): + + + +