Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
86 lines (71 loc) · 4.07 KB

CONTRIBUTING.md

File metadata and controls

86 lines (71 loc) · 4.07 KB

Contributing

Thank you for your interest in contributing! This document explains how collaborators and contributors can work with this repository to make meaningful, consistent contributions.

Table of Contents

  • Welcome
  • Code of Conduct
  • Getting started
  • Reporting issues
  • Proposing changes (Pull Requests)
  • Branching and commit conventions
  • Coding style and tests
  • Review process
  • Communication & support
  • Onboarding new collaborators
  • License & copyright

Welcome

We welcome contributions of all kinds: bug reports, documentation improvements, tests, examples, and code changes. If you're unsure where to start, look for issues labeled good first issue or help wanted, or say hello in the project's communication channels.

Code of Conduct

All contributors are expected to follow our Code of Conduct. Be respectful and professional in all interactions. If a Code of Conduct file exists in the repository, please read it; if not, maintain a friendly and inclusive tone.

Getting started

  1. Fork the repository (if applicable) and clone your fork: git clone https://github.com//.git
  2. Create a local branch for your work: git checkout -b feat/short-description or bugfix/short-description
  3. Install dependencies and run the test suite:
    • Follow the instructions in README.md for local setup
    • Run tests: (e.g., npm test, pytest, or other commands specified in README)

Reporting issues

  • Search existing issues before creating a new one.
  • Be descriptive: include steps to reproduce, expected vs actual behavior, environment (OS, versions), and logs or screenshots where helpful.
  • Use labels and templates if the repository provides them.

Proposing changes (Pull Requests)

  • Create a descriptive branch name (see Branching below).
  • Make small, focused changes with clear commit messages.
  • Open a pull request against the repository's main branch (or the branch indicated by maintainers).
  • In your PR description, include:
    • What problem the change solves
    • A short summary of the changes
    • Any relevant issue numbers (e.g., fixes #123)
    • How to test the change locally
  • Link to any related issues and add relevant labels if you can.

Branching and commit conventions

  • Branch naming examples:
    • feat/
    • fix/
    • docs/
    • chore/
  • Commit messages should be concise and follow this pattern:
    • (scope): Short summary
    • Body (optional): More detailed explanation, why the change was needed, and any notes about migration or backward compatibility.
    • Example: feat(api): add user search endpoint

Coding style and tests

  • Follow the project's existing style and linting rules. Run linter locally before submitting.
  • Add tests for new features and bug fixes. Ensure all tests pass.
  • If the project uses CI (e.g., GitHub Actions), your PR should pass all checks before merging.

Review process

  • PRs will be reviewed by maintainers and other collaborators.
  • Expect feedback and requested changes — respond promptly and iterate.
  • When approved, a maintainer may merge the PR, squash commits, or request a rebase.

Communication & support

  • Use the project's preferred channels (issues, discussions, Slack/Discord, etc.) for questions.
  • Be patient: maintainers are often volunteers and may need time to respond.

Onboarding new collaborators

  • If you are joining as a repository collaborator:
    • Introduce yourself and let maintainers know which areas you want to help with.
    • We may assign a mentor or point you to starter tasks.
    • Adhere to the same review and merge policies as other contributors.

License & copyright

  • Contributions are made under the repository's license. By contributing, you agree to license your contributions under the same terms.
  • If you have IP concerns, raise them privately with repository maintainers before submitting code.

If something here is unclear or you'd like a custom contributing guide (with templates, checklists, or CI details), tell us the repository name and any project conventions and I'll adapt this file to match.