|
| 1 | +# Contributing to Cline |
| 2 | + |
| 3 | +We're thrilled you're interested in contributing to Cline. Whether you're fixing a bug, adding a feature, or improving our docs, every contribution makes Cline smarter! To keep our community vibrant and welcoming, all members must adhere to our [Code of Conduct](CODE_OF_CONDUCT.md). |
| 4 | + |
| 5 | +## Reporting Bugs or Issues |
| 6 | + |
| 7 | +Bug reports help make Cline better for everyone! Before creating a new issue, please [search existing ones](https://github.com/cline/cline/issues) to avoid duplicates. When you're ready to report a bug, head over to our [issues page](https://github.com/cline/cline/issues/new/choose) where you'll find a template to help you with filling out the relevant information. |
| 8 | + |
| 9 | +<blockquote class='warning-note'> |
| 10 | + 🔐 <b>Important:</b> If you discover a security vulnerability, please use the <a href="https://github.com/cline/cline/security/advisories/new">Github security tool to report it privately</a>. |
| 11 | +</blockquote> |
| 12 | + |
| 13 | +## Deciding What to Work On |
| 14 | + |
| 15 | +Looking for a good first contribution? Check out issues labeled ["good first issue"](https://github.com/cline/cline/labels/good%20first%20issue) or ["help wanted"](https://github.com/cline/cline/labels/help%20wanted). These are specifically curated for new contributors and areas where we'd love some help! |
| 16 | + |
| 17 | +We also welcome contributions to our [documentation](https://github.com/cline/cline/tree/main/docs)! Whether it's fixing typos, improving existing guides, or creating new educational content - we'd love to build a community-driven repository of resources that helps everyone get the most out of Cline. You can start by diving into `/docs` and looking for areas that need improvement. |
| 18 | + |
| 19 | +If you're planning to work on a bigger feature, please create a [feature request](https://github.com/cline/cline/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop) first so we can discuss whether it aligns with Cline's vision. |
| 20 | + |
| 21 | +## Development Setup |
| 22 | + |
| 23 | +1. **VS Code Extensions** |
| 24 | + |
| 25 | + - When opening the project, VS Code will prompt you to install recommended extensions |
| 26 | + - These extensions are required for development - please accept all installation prompts |
| 27 | + - If you dismissed the prompts, you can install them manually from the Extensions panel |
| 28 | + |
| 29 | +2. **Local Development** |
| 30 | + - Run `npm run install:all` to install dependencies |
| 31 | + - Run `npm run test` to run tests locally |
| 32 | + - Before submitting PR, run `npm run format:fix` to format your code |
| 33 | + |
| 34 | +## Writing and Submitting Code |
| 35 | + |
| 36 | +Anyone can contribute code to Cline, but we ask that you follow these guidelines to ensure your contributions can be smoothly integrated: |
| 37 | + |
| 38 | +1. **Keep Pull Requests Focused** |
| 39 | + |
| 40 | + - Limit PRs to a single feature or bug fix |
| 41 | + - Split larger changes into smaller, related PRs |
| 42 | + - Break changes into logical commits that can be reviewed independently |
| 43 | + |
| 44 | +2. **Code Quality** |
| 45 | + |
| 46 | + - Run `npm run lint` to check code style |
| 47 | + - Run `npm run format` to automatically format code |
| 48 | + - All PRs must pass CI checks which include both linting and formatting |
| 49 | + - Address any ESLint warnings or errors before submitting |
| 50 | + - Follow TypeScript best practices and maintain type safety |
| 51 | + |
| 52 | +3. **Testing** |
| 53 | + |
| 54 | + - Add tests for new features |
| 55 | + - Run `npm test` to ensure all tests pass |
| 56 | + - Update existing tests if your changes affect them |
| 57 | + - Include both unit tests and integration tests where appropriate |
| 58 | + |
| 59 | +4. **Version Management with Changesets** |
| 60 | + |
| 61 | + - Create a changeset for any user-facing changes using `npm run changeset` |
| 62 | + - Choose the appropriate version bump: |
| 63 | + - `major` for breaking changes (1.0.0 → 2.0.0) |
| 64 | + - `minor` for new features (1.0.0 → 1.1.0) |
| 65 | + - `patch` for bug fixes (1.0.0 → 1.0.1) |
| 66 | + - Write clear, descriptive changeset messages that explain the impact |
| 67 | + - Documentation-only changes don't require changesets |
| 68 | + |
| 69 | +5. **Commit Guidelines** |
| 70 | + |
| 71 | + - Write clear, descriptive commit messages |
| 72 | + - Use conventional commit format (e.g., "feat:", "fix:", "docs:") |
| 73 | + - Reference relevant issues in commits using #issue-number |
| 74 | + |
| 75 | +6. **Before Submitting** |
| 76 | + |
| 77 | + - Rebase your branch on the latest main |
| 78 | + - Ensure your branch builds successfully |
| 79 | + - Double-check all tests are passing |
| 80 | + - Review your changes for any debugging code or console logs |
| 81 | + |
| 82 | +7. **Pull Request Description** |
| 83 | + - Clearly describe what your changes do |
| 84 | + - Include steps to test the changes |
| 85 | + - List any breaking changes |
| 86 | + - Add screenshots for UI changes |
| 87 | + |
| 88 | +## Contribution Agreement |
| 89 | + |
| 90 | +By submitting a pull request, you agree that your contributions will be licensed under the same license as the project ([Apache 2.0](LICENSE)). |
| 91 | + |
| 92 | +Remember: Contributing to Cline isn't just about writing code - it's about being part of a community that's shaping the future of AI-assisted development. Let's build something amazing together! 🚀 |
0 commit comments