arcade-mcp/CONTRIBUTING.md
Eric Gustin d6200c9d53
chore: add PR template aligned with engineering standards (#835)
## Summary

Adds a PR template at `.github/PULL_REQUEST_TEMPLATE.md` encoding the 6
hard gates and section scaffolding from the 2026-04-24 engineering
announcement ("What a Good Pull Request Looks Like"), and lightly
updates `CONTRIBUTING.md` to point at it. The repo had no PR template;
recent PR descriptions have been inconsistent in structure and ticket
linking.

Resolves: _(driven by the 2026-04-24 engineering announcement; no Linear
ticket but happy to file one if preferred)_

## Design decisions

- Single template, not a multi-template directory.

## Scope

In scope:
- `.github/PULL_REQUEST_TEMPLATE.md` (new)
- `CONTRIBUTING.md` "Pull Request Guidelines" section (additive update;
existing 3 bullets preserved)

Not in scope:
- CI enforcement of template fields or ticket-linking

## Author checklist

- [x] `make check`/`make test` n/a — no Python touched; pre-commit hooks
pass
- [x] Reviewed my own diff top-to-bottom
- [x] I'd merge it myself

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a
summary for commit d1f15d1e6b1a7521d01ace3c1379b330767f1fb9. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
2026-05-01 15:43:41 -07:00

143 lines
4.1 KiB
Markdown

# Contributing to `arcade-mcp`
Contributions are welcome, and they are greatly appreciated!
Every little bit helps, and credit will always be given.
You can contribute in many ways:
# Types of Contributions
## Report Bugs
Report bugs at https://github.com/ArcadeAI/arcade-mcp/issues
If you are reporting a bug, please include:
- Your operating system name and version.
- Any details about your local setup that might be helpful in troubleshooting.
- Detailed steps to reproduce the bug.
## Fix Bugs
Look through the GitHub issues for bugs.
Anything tagged with "bug" and "help wanted" is open to whoever wants to implement a fix for it.
## Implement Features
Look through the GitHub issues for features.
Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.
## Write Documentation
Arcade could always use more documentation, whether as part of the official docs, in docstrings, or even on the web in blog posts, articles, and such.
## Submit Feedback
The best way to send feedback is to file an issue at https://github.com/ArcadeAI/arcade-mcp/issues.
If you are proposing a new feature:
- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions
are welcome :)
# Get Started!
Ready to contribute? Here's how to set up `arcade-mcp` for local development.
Please note this documentation assumes you already have `uv` and `Git` installed and ready to go.
1. Fork the `arcade-mcp` repo on GitHub.
2. Clone your fork locally:
```bash
cd <directory_in_which_repo_should_be_created>
git clone git@github.com:YOUR_GITHUB_USERNAME/arcade-mcp.git
```
3. Now we need to install the environment. Navigate into the directory
```bash
cd arcade-mcp
```
Create your virtual environment
```bash
uv venv --python 3.11.6
```
4. Install the development environment and dependencies:
```bash
# Install all packages and development dependencies via uv workspace
uv sync --extra all --extra dev
# Install pre-commit hooks for code quality
uv run pre-commit install
```
Or use the convenient Makefile command that does both:
```bash
make install
```
The uv workspace will automatically handle installing all lib packages in the correct dependency order.
5. Create a branch for local development:
```bash
git checkout -b name-of-your-bugfix-or-feature
```
Now you can make your changes locally.
6. Don't forget to add test cases for your added functionality to the `libs/tests` directory.
7. When you're done making changes, check that your changes pass the formatting tests.
```bash
make check
```
Now, validate that all unit tests are passing:
```bash
make test
```
8. You can also run tests for specific components:
```bash
# Test all lib packages
make test
```
9. The CI/CD pipeline will run additional checks across different Python versions, so local testing with a single version is usually sufficient.
10. Commit your changes and push your branch to GitHub:
```bash
git add .
git commit -m "Your detailed description of your changes."
git push origin name-of-your-bugfix-or-feature
```
11. Submit a pull request through the GitHub website.
# Pull Request Guidelines
When you open a pull request, the [PR template](.github/PULL_REQUEST_TEMPLATE.md) will populate the description with prompts for a summary, ticket link, test plan, and a self-review checklist. Fill it in — it's the bar for moving from Draft to Ready for Review.
In short: PRs should be small and focused, tested through the end-user path (not just unit tests), and self-reviewed before you mark them Ready. The reviewer is your customer — craft the PR so they can read, understand, and approve it on the first pass.
Before you submit a pull request, check that it meets these guidelines:
1. The pull request should include tests.
2. If the pull request adds functionality, the [docs](https://github.com/ArcadeAI/docs) should be updated.
3. If making contributions to multiple servers (i.e. Google and Slack, etc.), submit a separate pull request for each.
This helps us segregate the changes during the review process making it more efficient.