Contributing

You can contribute by fixing issues, improving documentation, developing plugins, or submitting code. This guide follows the repository's CONTRIBUTING.md (Chinese) to help you prepare pull requests that are easy to review.

Development prerequisites

This project is built with Go, Wails, and Vue. Refer to their official documentation for details on these technologies.

Code contributors need a working knowledge of the relevant programming languages, development tools, and Git, and should be able to read existing code and independently perform basic builds, debugging, and validation. Maintainers focus on project issues and PR reviews. Their time and capacity are limited, so they cannot provide programming lessons from scratch or guidance throughout the entire development process. Please use relevant documentation and tutorials to learn the fundamentals. Thank you for your understanding.

Before opening a PR

Bug fixes and documentation updates can be submitted directly. For new features, architecture changes, or large refactors, open an issue and agree on the approach before starting development. Large PRs without prior discussion may not be reviewed or may need to be split and resubmitted.

Keep each PR focused on one independent problem. Include the code, tests, and documentation needed to solve it together. Submit unrelated dependency upgrades, formatting changes, or refactors separately. For example, a download fix can include a regression test and updated troubleshooting advice, but should not also redesign the settings page.

Read the architecture guide when you need context on module boundaries.

PR title and description

Use <type>: <short description> for the title and state the purpose of the change directly:

fix: correct Windows download paths
docs: improve English installation instructions
feat: add proxy configuration

Type	Purpose
feat	New functionality
fix	Bug fixes
perf	Performance improvements
refactor	Code restructuring without changing existing functionality
test	Added or updated tests
docs	Documentation, comments, or examples
ci	CI/CD or automation changes
chore	Dependency updates, configuration, or other maintenance

The PR description should explain:

• Problem and purpose: Link an existing issue and describe the trigger, current behavior, and expected result.
• Resulting behavior: Explain what changes and which platforms or features are affected. For UI changes, include before-and-after screenshots when helpful.
• Validation: List the checks and test commands you actually ran, their results, and anything still unverified. A successful compilation does not establish that every feature works.

Before submitting

• Confirm that the code compiles and complete checks and tests relevant to the change. Where practical, include a regression test that reproduces the bug being fixed.
• For UI, system integration, or platform-specific changes, describe the systems, steps, and results of manual verification. Clearly identify anything you could not verify.
• Review the diff for unrelated changes, local configuration, caches, and build output. Do not commit node_modules/, frontend/dist/, docs/.vitepress/cache/, or docs/.vitepress/dist/.
• When changing dependencies, update both manifests and lockfiles. Review and include relevant changes to auto-imports.d.ts or components.d.ts generated by the frontend build.
• Update relevant documentation, examples, and translations when features, settings, workflows, or public interfaces change.
• Sanitize logs, screenshots, and fixtures. Do not commit cookies, Authorization headers, account details, passwords, or privately signed resource URLs.

Frontend changes require Node.js 22.12 or later. Run from the repository root:

cd frontend
npm ci
npm run check
npm run build

These commands check types and produce a static build. Manually verify client interactions affected by your changes as well.

Documentation contributions

Corrections, screenshots, clearer instructions, and translations can be submitted directly as PRs. User guides should explain where to find a control, what an option does, and how to solve a problem.

Documentation should focus on this project's usage, configuration, troubleshooting, interface conventions, and contribution workflow. Retain necessary environment requirements, build commands, and project examples. Avoid adding introductory programming lessons, language syntax tutorials, or basic development-tool instructions unrelated to the project. Link to relevant official documentation for general knowledge instead of reproducing it here.

Multilingual documentation

• Chinese and English pages live in docs/zh/ and docs/en/, with matching relative directories and filenames. Keep titles, description metadata, body text, and link labels synchronized when adding or changing content.
• On the website, Chinese pages use the root path and English pages use the /en/ prefix; source directories stay unchanged. For example, docs/zh/guide/settings.md maps to /guide/settings.html. Absolute links in homepages and navigation should use website paths.
• Give each page a clear level-one heading and a concise, accurate description in its frontmatter.
• Use relative .md links between documents. Check heading links after renaming headings. When adding, moving, or deleting pages, update navigation, homepage links, and other references in both languages.
• Images and public SDK files are shared under docs/public/; do not duplicate them in language directories. Documentation uses asset paths such as /images/ and /plugin-sdk/, while repository READMEs use relative paths under docs/public/.
• When adding a language, provide complete translations, navigation, and interface text so the language menu can open corresponding pages.

Check documentation changes

Documentation dependencies are managed independently in docs/ and require Node.js 22 or later. Run from the repository root:

cd docs
npm ci
npm run check
npm run build

Before submitting, check the changed pages' formatting, images, links, heading anchors, and Chinese and English content. For a local preview, run npm run dev in docs/; the default address is http://127.0.0.1:8088. Include page sources and necessary assets in the PR.

Plugin contributions

For new site support, develop a standalone plugin instead of adding site checks to the generic downloader. Refer to the plugin developer guide and examples, and provide at least one offline fixture without private data.

Public plugins can follow the extension store publishing guide without merging their code into the main project.

Issue reports and review

When opening a GitHub issue, include your operating system, app and relevant plugin versions, reproducible steps, actual and expected results, and sanitized error messages or logs.

Maintainer time is limited, so issue replies and PR reviews may take time. Add information to the existing discussion instead of submitting duplicates or repeatedly asking for updates. Address review feedback in the original PR.