d676b3b39a
### What this PR does Before this PR: - No Zed editor configuration example existed for contributors using Zed - Several config files had inconsistent JSON array formatting - `biome.jsonc` had redundant exclude rules - Contributing guides did not reference the development guide - `development.md` (zh) was not translated to Chinese - Node.js and pnpm versions were hardcoded in the development guide After this PR: - Added `.zed/settings.json.example` with Biome formatter, oxc/eslint/biome fixAll, and import organization - Cleaned up redundant Biome exclude rules and unified JSON array formatting - Added "Setting Up Your Development Environment" section to `CONTRIBUTING.md` (en/zh) linking to the development guide - Added Zed editor setup guide to `development.md` (en/zh) - Translated `docs/zh/guides/development.md` to Chinese - Node.js version now references `.node-version`; pnpm version references `packageManager` in `package.json` - VSCode extensions now reference `.vscode/extensions.json` ### Why we need it and why it was done in this way The following tradeoffs were made: - The Zed settings file is provided as an `.example` rather than a direct `.zed/settings.json` to avoid overriding individual contributor preferences. - Versions reference their source of truth files rather than being hardcoded, so docs stay in sync automatically. The following alternatives were considered: - N/A ### Breaking changes None ### Special notes for your reviewer - The JSON formatting changes are purely cosmetic — no behavior changes. They align with Biome's default formatting rules. - The `.zed/settings.json.example` includes `source.fixAll.eslint` and `source.fixAll.oxc` alongside Biome, matching the project's triple-linter setup. ### Checklist - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: [Write code that humans can understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans) and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle) - [x] Refactor: You have [left the code cleaner than you found it (Boy Scout Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) - [x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [x] Documentation: A [user-guide update](https://docs.cherry-ai.com) was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior. - [x] Self-review: I have reviewed my own code (e.g., via [`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`, or GitHub UI) before requesting review from others ### Release note ```release-note NONE ``` --------- Signed-off-by: icarus <eurfelux@gmail.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
6.6 KiB
Cherry Studio Contributor Guide
Welcome to the Cherry Studio contributor community! We are committed to making Cherry Studio a project that provides long-term value and hope to invite more developers to join us. Whether you are an experienced developer or a beginner just starting out, your contributions will help us better serve users and improve software quality.
How to Contribute
Here are several ways you can participate:
-
Contribute Code: Help us develop new features or optimize existing code. Please ensure your code adheres to our coding standards and passes all tests.
-
Fix Bugs: If you find a bug, you are welcome to submit a fix. Please confirm the issue is resolved before submitting and include relevant tests.
-
Maintain Issues: Help us manage issues on GitHub by assisting with tagging, classifying, and resolving problems.
-
Product Design: Participate in product design discussions to help us improve user experience and interface design.
-
Write Documentation: Help us improve the user manual, API documentation, and developer guides.
-
Community Maintenance: Participate in community discussions, help answer user questions, and promote community activity.
-
Promote Usage: Promote Cherry Studio through blogs, social media, and other channels to attract more users and developers.
Before You Start
Please make sure you have read the Code of Conduct and the LICENSE.
Setting Up Your Development Environment
Please refer to the Developer Guide for instructions on setting up your local development environment, including prerequisites, installation steps, and available commands.
For a comprehensive overview of the project architecture, tech stack, conventions, and available commands, see CLAUDE.md.
Getting Started
To help you get familiar with the codebase, we recommend tackling issues tagged with one or more of the following labels: good-first-issue, help-wanted, or kind/bug. Any help is welcome.
Testing
Features without tests are considered non-existent. To ensure code is truly effective, relevant processes should be covered by unit tests and functional tests. Therefore, when considering contributions, please also consider testability. All tests can be run locally without dependency on CI. Please refer to the "Testing" section in the Developer Guide.
Automated Testing for Pull Requests
Automated tests are triggered on pull requests (PRs) opened by members of the Cherry Studio organization, except for draft PRs. PRs opened by new contributors will initially be marked with the needs-ok-to-test label and will not be automatically tested. Once a Cherry Studio organization member adds /ok-to-test to the PR, the test pipeline will be created.
Consider Opening Your Pull Request as a Draft
Not all pull requests are ready for review when created. This might be because the author wants to start a discussion, they are not entirely sure if the changes are heading in the right direction, or the changes are not yet complete. Please consider creating these PRs as draft pull requests. Draft PRs are skipped by CI, thus saving CI resources. This also means reviewers will not be automatically assigned, and the community will understand that this PR is not yet ready for review. Reviewers will be assigned after you mark the draft pull request as ready for review.
Contributor Compliance with Project Terms
We require every contributor to certify that they have the right to legally contribute to our project. Contributors express this by consciously signing their commits, thereby indicating their compliance with the LICENSE. A signed commit is one where the commit message includes the following:
You can generate a signed commit using the following command git commit --signoff:
git commit --signoff -m "Your commit message"
Getting Code Reviewed/Merged
Maintainers are here to help you implement your use case within a reasonable timeframe. They will do their best to review your code and provide constructive feedback promptly. However, if you get stuck during the review process or feel your Pull Request is not receiving the attention it deserves, please contact us via comments in the Issue or through the Community.
Participating in the Test Plan
The Test Plan aims to provide users with a more stable application experience and faster iteration speed. For details, please refer to the Test Plan.
Other Suggestions
- Contact Developers: Before submitting a PR, you can contact the developers first to discuss or get help.
Important Contribution Guidelines & Focus Areas
Please review the following critical information before submitting your Pull Request:
Temporary Restriction on Data-Changing Feature PRs 🚫
Currently, we are NOT accepting feature Pull Requests that introduce changes to our Redux data models or IndexedDB schemas.
Our core team is currently focused on significant architectural updates that involve these data structures. To ensure stability and focus during this period, contributions of this nature will be temporarily managed internally.
- PRs that require changes to Redux state shape or IndexedDB schemas will be closed.
- This restriction is temporary and will be lifted with the release of
v2.0.0. You can track the progress ofv2.0.0and its related discussions on issue #10162.
We highly encourage contributions for:
- Bug fixes 🐞
- Performance improvements 🚀
- Documentation updates 📚
- Features that do not alter Redux data models or IndexedDB schemas (e.g., UI enhancements, new components, minor refactors). ✨
We appreciate your understanding and continued support during this important development phase. Thank you!
Contact Us
If you have any questions or suggestions, feel free to contact us through the following ways:
- WeChat: kangfenmao
- GitHub Issues
Thank you for your support and contributions! We look forward to working with you to make Cherry Studio a better product.