| Developers interested in other languages | [pymilvus](https://github.com/milvus-io/pymilvus), [milvus-sdk-node](https://github.com/milvus-io/milvus-sdk-node), [milvus-sdk-java](https://github.com/milvus-io/milvus-sdk-java) | [Contributing to PyMilvus](https://github.com/milvus-io/pymilvus/blob/master/CONTRIBUTING.md) |
| Developers interested in other languages | [pymilvus](https://github.com/milvus-io/pymilvus), [milvus-sdk-node](https://github.com/milvus-io/milvus-sdk-node), [milvus-sdk-java](https://github.com/milvus-io/milvus-sdk-java) | [Contributing to PyMilvus](https://github.com/milvus-io/pymilvus/blob/master/CONTRIBUTING.md)|
| Tech writers and docs enthusiasts | [milvus-docs](https://github.com/milvus-io/milvus-docs)| [Contributing to milvus docs](https://github.com/milvus-io/milvus-docs/blob/v2.0.0/CONTRIBUTING.md) |
| Web developers | [milvus-insight](https://github.com/zilliztech/milvus-insight) | |
## How can you contribute?
### Contributing code
**If you encountered a bug, you can**
- (**Recommended**) File an issue about the bug.
- Provide clear and concrete ways/scripts to reproduce the bug.
- Provide possible solutions for the bug.
- Pull a request to fix the bug.
**If you're interested in existing issues, you can**
- (**Recommended**) Provide answers for issue labeled `question`.
- Provide help for issues labeled `bug`, `improvement`, and `enhancement` by
- (**Recommended**) Ask questions, reproduce the issue, or providie solutions.
- Pull a request to fix the issue.
- (**Recommended**) Ask questions, reproduce the issue, or providie solutions.
- Pull a request to fix the issue.
**If you require new feature or major enhancement, you can**
- (**Recommended**) File an issue about the feature/enhancement with reasons.
- Provide a MEP for the feature/enhancement.
- Pull a request to implement the MEP.
**If you are a reviewer/approver of Milvus, you can**
- Participate in [PR review](CODE_REVIEW.md) process.
- Instruct newcomers in the community to complete the PR process.
...
...
@@ -77,7 +82,7 @@ Generally, we follow the "fork-and-pull" Git workflow.
Remember to [sync your forked repository](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#keep-your-fork-synced)*before* submitting proposed changes upstream. If you have an existing local repository, please update it before you start, to minimize the chance of merge conflicts.
Remember to [sync your forked repository](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#keep-your-fork-synced)_before_ submitting proposed changes upstream. If you have an existing local repository, please update it before you start, to minimize the chance of merge conflicts.
Before submitting your pull requests for review, make sure that your changes are consistent with the [coding style](CONTRIBUTING.md#coding-style), and run [unit tests](CONTRIBUTING.md#run-unit-test-with-code-coverage) to check your code coverage rate.
-Include unit tests when you contribute new features, as they help to prove that your code works correctly, and also guard against future breaking changes to lower the maintenance cost.
-Bug fixes also require unit tests, because the presence of bugs usually indicates insufficient test coverage.
-Keep API compatibility in mind when you change code in Milvus. Reviewers of your pull request will comment on any API compatibility issues.
-When you contribute a new feature to Milvus, the maintenance burden is (by default) transferred to the Milvus team. This means that the benefit of the contribution must be compared against the cost of maintaining the feature.
- Include unit tests when you contribute new features, as they help to prove that your code works correctly, and also guard against future breaking changes to lower the maintenance cost.
- Bug fixes also require unit tests, because the presence of bugs usually indicates insufficient test coverage.
- Keep API compatibility in mind when you change code in Milvus. Reviewers of your pull request will comment on any API compatibility issues.
- When you contribute a new feature to Milvus, the maintenance burden is (by default) transferred to the Milvus team. This means that the benefit of the contribution must be compared against the cost of maintaining the feature.
### Developer Certificate of Origin (DCO)
...
...
@@ -120,43 +125,51 @@ Keeping a consistent style for code, code comments, commit messages, and PR desc
We highly recommend you refer to and comply to the following style guides when you put together your pull requests:
### Golang coding style
- Coding style: refer to the [Effictive Go Style Guide](https://golang.org/doc/effective_go)
We also use `golangci-lint` to perform code check. Run the following command before submit your pull request and make sure there is no issue reported:
```shell
$ make static-check
```
To format code
```shell
$ make fmt
```
### C++ coding style
The C++ coding style used in Milvus generally follows [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html).
And we made the following changes based on the guide:
-4 spaces for indentation
-Adopt .cpp file extension instead of .cc extension
-120-character line length
-Camel-Cased file names
- 4 spaces for indentation
- Adopt .cpp file extension instead of .cc extension
- 120-character line length
- Camel-Cased file names
Install clang-format
```shell
$ sudo apt-get install clang-format
```
Check code style
```shell
$ make cppcheck
```
## Run unit test with code coverage
Before submitting your Pull Request, make sure you have run unit test, and your code coverage rate is >= 90%.
### Run golang unit tests
You can run all the Golang unit tests using make.
```shell
$ make test-go
```
...
...
@@ -173,20 +186,26 @@ You can run a sub unit test.
In this case, we only concern about the tests with name "SegmentReplica" and
sub tests with name "segmentFlushed". When running sub tests, the coverage is not concerned.
```shell
$ go test ./internale/datanode -run SegmentReplica/segmentFlushed
ok github.com/milvus-io/milvus/internal/datanode 0.019s
```
### Run C++ unit tests
Install lcov
```shell
$ sudo apt-get install lcov
```
Run unit test and generate code for code coverage check
```shell
$ make codecov-cpp
```
## Commits and PRs
- Commit message and PR description style: refer to [good commit messages](https://chris.beams.io/posts/git-commit)
