|
1 | | -# Contributor Guide |
| 1 | +# Contributor Guidelines |
2 | 2 |
|
3 | | -_Welcome to offer PRs, bug reports, documentation supplements or other types of contributions to SWIFT!_ |
| 3 | +*Welcome to contribute Feature PRs, Bug reports, documentation, or other types of contributions to twinkle!* |
4 | 4 |
|
5 | 5 | ## Table of Contents |
| 6 | + |
6 | 7 | - [Code of Conduct](#-code-of-conduct) |
7 | 8 | - [Contribution Process](#-contribution-process) |
8 | | -- [Hardware support](#-Hardware-support) |
| 9 | +- [Resource Support](#-resource-support) |
9 | 10 |
|
10 | 11 | ## 📖 Code of Conduct |
11 | | -Please refer to our [Code of Conduct documentation](./CODE_OF_CONDUCT.md). |
| 12 | + |
| 13 | +Please refer to our [Code of Conduct document](./CODE_OF_CONDUCT.md). |
12 | 14 |
|
13 | 15 | ## 🔁 Contribution Process |
| 16 | + |
14 | 17 | ### What We Need |
15 | | -- 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. |
16 | | -- 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. |
17 | | -- 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. |
| 18 | + |
| 19 | +- New components: You can contribute excellent components to the twinkle project, or contribute them to the modelhub in the ModelScope/Hugging Face community following the component protocol, making them available for other developers to use |
| 20 | +- New kernels: You can contribute low-level kernels to the twinkle project. These kernels can be integrated into models to achieve better training value |
| 21 | + |
| 22 | +Your contributions will help other developers. Please add your component name, location, and usage documentation link in the Community Components section of the README in your code PR. |
18 | 23 |
|
19 | 24 | ### Incentives |
20 | | -- we will issue electronic certificates to contributors on behalf of the ModelScope community, to encourage your selfless contributions. |
21 | | -- We will offer small souvenirs related to the ModelScope Community. |
22 | | -- We will provide free A10 computing power during the development period. For more details, please refer to [Hardware-support](#-Hardware-support) section. |
23 | | - |
24 | | -### Submitting PR (Pull Requests) |
25 | | - |
26 | | -Any feature development is carried out in the form of Fork and then PR on GitHub. |
27 | | -1. Fork: Go to the [ms-swift](https://github.com/modelscope/ms-swift) page and click the **Fork button**. After completion, a SWIFT code repository will be cloned under your personal organization. |
28 | | -2. 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 `main` branch to prevent code expiration and conflicts. |
29 | | -3. 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/swift:main` branch as the target branch. |
30 | | - |
31 | | -4. Write Description: It is necessary to provide a good feature description in the PR, so that the reviewers know the content of your modification. |
32 | | -5. 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. |
33 | | - |
34 | | -### Code Standards and Development Approach |
35 | | -SWIFT has conventional variable naming conventions and development approaches. Please follow these approaches as much as possible during development. |
36 | | -1. Variable names are separated by underscores, and class names are named with the first letter of each word capitalized. |
37 | | -2. All Python indentation uses four spaces instead of a tab. |
38 | | -3. Choose well-known open-source libraries, avoid using closed-source libraries or unstable open-source libraries, and avoid repeating the existing code. |
39 | | - |
40 | | -After the PR is submitted, SWIFT will perform two types of tests: |
41 | | -- Code Lint Test: A static code compliance check test. please make sure that you have performed code lint locally in advance. |
42 | | -```shell |
43 | | -pip install pre-commit # In the swift folder |
44 | | -pre-commit run --all-files # Fix the errors reported by pre-commit until all checks are successful |
45 | | -``` |
46 | | -- CI Tests: Smoke tests and unit tests, please refer to the next section. |
47 | 25 |
|
48 | | -### Running CI Tests |
49 | | -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. |
| 26 | +- We will issue electronic certificates to contributors on behalf of the ModelScope community to acknowledge your selfless contributions. |
| 27 | +- We will give away ModelScope community merchandise and small gifts. |
| 28 | + |
| 29 | +### Submitting PRs (Pull Requests) |
| 30 | + |
| 31 | +All feature development is conducted on GitHub using a Fork-then-PR workflow. |
| 32 | + |
| 33 | +1. Fork: Go to the [twinkle](https://github.com/modelscope/twinkle) page and click the **Fork button**. This will clone a twinkle repository under your personal organization |
| 34 | + |
| 35 | +2. Clone: Clone the repository created in step one to your local machine and **create a new branch** for development. During development, please click the **Sync Fork button** regularly to sync with the `main` branch to prevent code from becoming outdated and causing conflicts |
50 | 36 |
|
51 | | -Additionally, since some important tests have been skipped due to long running time, to ensure that your logic is correct, you can run the test locally: |
52 | | -```shell |
53 | | -python tests/llm/test_run.py |
54 | | -``` |
55 | | -Please make sure this test can pass normally. |
| 37 | +3. Submit PR: After development and testing are complete, push your code to the remote branch. On GitHub, click the **Pull Requests page** and create a new PR. Select your code branch as the source branch and `modelscope/twinkle:main` as the target branch |
56 | 38 |
|
57 | | -## ✅ Hardware support |
| 39 | +4. Write Description: It is essential to provide a good feature description in your PR so that reviewers understand your changes |
| 40 | + |
| 41 | +5. Review: We want the merged code to be clean and efficient, so we may raise some questions for discussion. Please note that any questions raised during review are about the code itself, not about you personally. Once all issues have been discussed and resolved, your code will be approved |
| 42 | + |
| 43 | +### Code Standards and Development Practices |
| 44 | + |
| 45 | +twinkle has established conventions for variable naming and development practices. Please try to follow these conventions during development. |
| 46 | + |
| 47 | +1. Variable names use underscore separation; class names use PascalCase (capitalize the first letter of each word) |
| 48 | +2. All Python indentation uses four spaces instead of one tab |
| 49 | +3. Use well-known open-source libraries; avoid closed-source or unstable open-source libraries; avoid reinventing the wheel |
| 50 | + |
| 51 | +twinkle runs two types of tests after a PR is submitted: |
| 52 | + |
| 53 | +- Code Lint Tests: Static code analysis tests. To ensure this test passes, please run Code lint locally beforehand. Here's how: |
| 54 | + |
| 55 | + ```shell |
| 56 | + pip install pre-commit |
| 57 | + pre-commit run --all-files |
| 58 | + # Fix any errors reported by pre-commit until all checks pass |
| 59 | + ``` |
| 60 | + |
| 61 | +- CI Tests: Smoke tests and unit tests. Please refer to the next section |
| 62 | + |
| 63 | +### Running CI Tests |
58 | 64 |
|
59 | | -SWIFT will provide hardware support for developers, including free GPUs. If needed, please email us ([contact@modelscope.cn](mailto:contact@modelscope.cn)) or join our WeChat group: |
| 65 | +Before submitting a PR, please ensure your development code is protected by test cases. For example, smoke tests for new features, or unit tests for various edge cases. Reviewers will also pay attention to this during code review. Additionally, a dedicated service will run CI Tests, executing all test cases. Code can only be merged after all test cases pass. |
60 | 66 |
|
61 | | -<p align="left"> |
62 | | -<img src="asset/wechat.png" width="250" style="display: inline-block;"> |
63 | | -</p> |
| 67 | +Please ensure these tests pass successfully. |
0 commit comments