Welcome to offer PRs, bug reports, documentation supplements or other types of contributions to SWIFT!
Please refer to our Code of Conduct documentation.
- New Technologies and New Models: SWIFT needs to support more open-source models and datasets, or new technologies that we have not paid attention to. If you are interested please submit a PR to us.
- Technical Propagation: If you are interested in technical propagation, you are welcome to help us write tutorials, documents or videos on any website, and send us the link.
- Community Contribution: You can write technical articles related to SWIFT, and submit them to us. After review and approval, we will publish them on the official ModelScope accounts (Zhihu, WeChat, etc.), with your name assigned.
- we will issue electronic certificates to contributors on behalf of the ModelScope community, to encourage your selfless contributions.
- We will offer small souvenirs related to the ModelScope Community.
- We will provide free A10 computing power during the development period. For more details, please refer to Hardware-support section.
Any feature development is carried out in the form of Fork and then PR on GitHub.
-
Fork: Go to the ms-swift page and click the Fork button. After completion, a SWIFT code repository will be cloned under your personal organization.
-
Clone: Clone the code repository generated in the first step to your local machine and create a new branch for development. During development, please click the Sync Fork button in time to synchronize with the
mainbranch to prevent code expiration and conflicts. -
Submit PR: After development and testing, push the code to the remote branch. On GitHub, go to the Pull Requests page, create a new PR, select your code branch as the source branch, and the
modelscope/ms-swift:mainbranch as the target branch. -
Write Description: Fill in the PR template — keep the PR type checkboxes, the linked-issue line and the checklist, and tick the boxes that apply; the template is not auto-filled for PRs created via CLI/API (e.g.
gh pr create --body ...), so include the template content yourself. Link the related issue if there is one (e.g.Fixes #123for bug fixes, orRefs #123for features/RFCs), and describe your changes so that the reviewers know the content of your modification. PRs that do not follow the template may be closed directly. -
Review: We hope that the code to be merged is concise and efficient, so we may raise some questions and discuss them. Please note that any issues raised in the review are aimed at the code itself, not at you personally. Once all issues are discussed and resolved, your code will be approved.
If you are contributing to SWIFT for the first time, please follow this process:
- Open an issue first (using the issue templates we provide), describing the problem you have found or the feature you would like to develop.
- Open a pull request and link the issue in the PR description (e.g.
Fixes #123).
This avoids duplicate work and ensures that your contribution can be merged. Pull requests from first-time contributors that do not link an issue may be closed directly.
We welcome AI-assisted contributions — AI tools can help you write better code, catch issues early, and get familiar with the codebase faster. The quality bar is the same for every PR, no matter how it was produced.
- You are responsible for every line: review and understand all changed lines yourself, validate the behavior end-to-end, and run the relevant tests before submitting. You should be able to explain how the change works and why it is correct; maintainers may ask about the details.
- Pure agent PRs are not accepted: do not simply forward a change generated by an agent that you cannot understand or vouch for. Reviewing such changes is costly for maintainers, so these PRs will be rejected.
- Avoid one-off "busywork" PRs: single typo fixes, isolated style cleanups, or "theoretical bugs" without a real usage path are hard to justify under the current review load. Bundle mechanical cleanups into a systematic change, or open an issue to discuss first.
SWIFT has conventional variable naming conventions and development approaches. Please follow these approaches as much as possible during development.
- Variable names are separated by underscores, and class names are named with the first letter of each word capitalized.
- All Python indentation uses four spaces instead of a tab.
- Choose well-known open-source libraries, avoid using closed-source libraries or unstable open-source libraries, and avoid repeating the existing code.
After the PR is submitted, SWIFT will perform two types of tests:
- Code Lint Test: A static code compliance check test. please make sure that you have performed code lint locally in advance.
pip install pre-commit # In the swift folder
pre-commit run --all-files # Fix the errors reported by pre-commit until all checks are successful- CI Tests: Smoke tests and unit tests, please refer to the next section.
Before submitting the PR, please ensure that your development code is protected by test cases, such as smoke tests for new features, or unit tests for various edge cases. Reviewers will also pay attention to this during code review. At the same time, there will be dedicated services running CI Tests, running all test cases, and the code can only be merged after the test cases pass.
ModelScope provides developers with free A10 GPU computing resources. For more details, please refer to the ModelScope Notebook.
ms-swift Training WeChat Group:
