Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
95 lines (69 loc) · 4.59 KB

CONTRIBUTING.md

File metadata and controls

95 lines (69 loc) · 4.59 KB

Contributing

First off, thanks for taking the time to contribute! ❤️

Code of Conduct

This project follows the core values of the Contributor Covenant Code of Conduct.

Reporting a bug

  1. Check first that the bug isn't already filed — search both open and closed issues. If you find a match, add a 👍 reaction or a comment with new information rather than opening a duplicate.
  2. Use the issue template when opening an issue.

Proposing a change

The kinds of pull requests we welcome:

  • Fixes for clearly identified bugs. The pull request description must explain what is being fixed and how to verify it. A regression test is expected.
  • New features that solve a use case shared by a meaningful portion of users. Please open an issue first and wait for a maintainer to confirm the direction before writing code.
  • Chores: typos, comment clarifications. Multiple typos or comment fixes can be combined into a single pull request.

What we'll generally decline:

  • Stylistic refactors that don't improve performance, correctness, or testability. Code style is subjective and large diffs make git blame worse. We're happy to accept small, principled cleanups alongside other work.
  • Changes which result in a breaking change.
  • "Drive-by" pull requests where the contributor isn't available to address review comments.

Pull request guidelines

  • One concern per pull request. Smaller pull requests get faster reviews.
  • Tests are required for bug fixes (regression test) and new features (coverage of the new path).
  • Ensure you fix all errors reported by our CI. Note that CI runs have to be approved by a maintainer.
    • ⚠️ A lot of our e2e tests use the tps-action. This action will fail for unauthorized users. Expect them to fail, if you are not part of our organization. A maintainer will run the e2e tests. If you decide on running them on your own costs, feel free to share the results.
  • Allow edits from maintainers when you open the pull request, so we can rebase or make small fixups directly.
  • Don't force-push after a maintainer has started reviewing. Push new commits; we squash on merge.
  • Pull request titles should follow the Conventional Commits pattern because the title becomes the squash-merge commit message (see Commit messages for details); update the title and body if the change drifts during review.

Commit messages

We use Conventional Commits. The format matters because releaser-pleaser generates our changelogs from it.

<type>(<optional scope>): <short imperative summary, ≤72 chars>

<optional longer body explaining the why, wrapped at ~72 chars>

<optional footers, e.g. Fixes #123, BREAKING CHANGE: ...>

Common types: feat, fix, chore, docs, test, refactor, ci, build. A feat: triggers a minor release, a fix: triggers a patch release.

Examples:

  • feat(server-type): add support for ARM64 server types
  • fix(load-balancer): retry transient 503s from the API
  • docs: clarify token scopes in README

AI / LLM policy

You may use AI assistants when contributing, provided every one of the following is met:

  • Disclose in the pull request description (or issue) that you used an AI tool, and which one. One short line is enough.
  • You are accountable. You must understand every change you submit well enough to explain it, defend it in review, and revise it without further AI help if the reviewer asks. Pull requests from contributors who can't engage with review comments will be closed.
  • Submitted by a human. pull requests must come from a real, human-owned GitHub account. We don't accept submissions from bot accounts or unattended agents.
  • Quality bar is unchanged. AI-generated boilerplate, half-finished code, plausible-but-wrong fixes, or hallucinated APIs will be closed.
  • Cap on open AI-assisted pull requests. Contributors may have at most two open AI-assisted pull request(s) at a time. This protects review capacity. Maintainers are not subject to this cap.

Licensing

By submitting a contribution, you agree that it is licensed under the same license as the repository you're contributing to. See each repository's LICENSE file.

Thanks for contributing. If something in these guidelines is unclear or seems to be missing, please open an issue or pull request — they apply to themselves.