Write a CONTRIBUTING Guide

A CONTRIBUTING.md file is a signal of a healthy, welcoming open-source project. GitHub automatically surfaces it with a link in the repository sidebar and displays it to contributors before they submit their first issue or pull request. It sets expectations, reduces the back-and-forth that happens when contributors don't follow the project's conventions, and makes maintainers' review work easier by ensuring contributions arrive in the expected format. This template covers the four most important sections of a contributing guide: how to report issues, how to set up the development environment, the pull request process, and commit message conventions. Together, these sections answer every common question a first-time contributor asks before making their first contribution. The issue reporting section is valuable even before any contribution is made: it tells reporters what information to include upfront, reducing the most common maintainer response ("can you share steps to reproduce?"). Explicitly asking for steps to reproduce, expected vs actual behavior, and version information in the template saves rounds of follow-up questions. The development setup section should contain the exact commands to get from a fresh clone to a running development environment. No assumptions about what tools are installed (except explicit prerequisites). Copy these commands, run them in order, and development should work. When this section is accurate, onboarding takes minutes rather than hours of fighting environment setup issues. The pull request process defines the social contract for contributions: fork the repo, create a feature branch (not committing directly to main), make changes with tests, ensure tests and lint pass locally before submitting, and write a clear PR description explaining what changed and why. These simple expectations, stated explicitly, prevent the most common reasons PRs get rejected or stalled in review. Conventional Commits format (feat:, fix:, docs:, refactor:) is increasingly adopted because it enables automated changelog generation and semantic versioning. Tools like semantic-release read the commit history and automatically determine whether a release should be a major, minor, or patch bump based on the prefix. Including a brief explanation of this format in CONTRIBUTING.md ensures contributors' commits work with your automation. Where to place the file: GitHub looks for CONTRIBUTING.md in the repository root, the docs/ directory, or the .github/ directory. All three locations trigger GitHub's automatic linking when contributors open issues or PRs. The .github/ directory is the cleanest option as it keeps repository metadata separate from project documentation and code.

# Contributing to Project Name

Thank you for considering a contribution!

## Reporting Issues

Before opening an issue, search existing issues to avoid duplicates.
Include: steps to reproduce, expected vs actual behavior, and version info.

## Development Setup

```bash
git clone https://github.com/user/repo
cd repo
npm install
npm run dev
```

## Pull Request Process

1. Fork the repository and create a feature branch
2. Make your changes with tests
3. Run `npm test` and `npm run lint`
4. Submit a PR with a clear description of the change

## Commit Messages

Follow [Conventional Commits](https://www.conventionalcommits.org/):
- `feat: add dark mode`
- `fix: correct timezone handling`
- `docs: update API reference`

## Code of Conduct

This project follows the [Contributor Covenant](https://www.contributor-covenant.org/).