Update CONTRIBUTING.md

#166
This commit is contained in:
yangyshdan 2018-11-07 22:45:40 +08:00 committed by GitHub
parent cfca827a14
commit 6a26a9d220
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -1,31 +1,72 @@
## How To Contribute
# Contributing to Nacos
We are always very happy to have contributions, whether for trivial cleanups or big new features.
We want to have high quality, well documented codes for each programming language.
Welcome to Nacos! This document is a guideline about how to contribute to Nacos.
If you find something incorrect or missing, please leave comments / suggestions.
Nor is code the only way to contribute to the project. We strongly value documentation, integration with other project, and gladly accept improvements for these aspects.
## Before you get started
## Contributing code
### Code of Conduct
To submit a change for inclusion, please do the following:
Please make sure to read and observe our [Code of Conduct](./CODE_OF_CONDUCT.md).
#### If the change is non-trivial please include some unit tests that cover the new functionality.
#### If you are introducing a completely new feature or API it is a good idea to start a wiki and get consensus on the basic design first.
#### It is our job to follow up on patches in a timely fashion. Nag us if we aren't doing our job (sometimes we drop things).
## Becoming a Committer
## Contributing
We are always interested in adding new contributors. What we look for are series of contributions, good taste and ongoing interest in the project. If you are interested in becoming a committer, please let one of the existing committers know and they can help you walk through the process.
We are always very happy to have contributions, whether for typo fix, bug fix or big new features.
Please do not ever hesitate to ask a question or send a pull request.
Nowadays,we have several important contribution points:
#### Wiki & JavaDoc
#### Nacos Console
#### Nacos SDK(C++\.Net\Php\Python\Go\Node.js)
We strongly value documentation and integration with other projects such as Spring Cloud, Kubernetes, Dubbo, etc.
We are very glad to accept improvements for these aspects.
##### Prerequisite
If you want to contribute the above listing points, you must abide our some prerequisites:
###### Readability - API must have Javadoc,some very important methods also must have javadoc
###### Testability - 80% above unit test coverage about main process
###### Maintainability - Comply with our [PMD spec](style/codeStyle.xml), and at least 3 month update frequency
###### Deployability - We encourage you to deploy into [maven repository](http://search.maven.org/)
### Open an issue / PR
We use [GitHub Issues](https://github.com/alibaba/Nacos/issues) and [Pull Requests](https://github.com/alibaba/Nacos/pulls) for trackers.
If you find a typo in document, find a bug in code, or want new features, or want to give suggestions,
you can [open an issue on GitHub](https://github.com/alibaba/Nacos/issues/new) to report it.
Please follow the guideline message in the issue template.
If you want to contribute, please follow the [contribution workflow](#github-workflow) and create a new pull request.
If your PR contains large changes, e.g. component refactor or new components, please write detailed documents
about its design and usage.
If you just want to contribute directly
### Begin yoru development
We use the `develop` branch as the development branch, which indicates that this is a unstable branch.
Here are the workflow for contributors:
1. Fork to your own
2. Clone fork to local repository
3. Create a new branch and work on it
4. Keep your branch in sync
5. Commit your changes (make sure your commit message concise)
6. Push your commits to your forked repository
7. Create a pull request. please follow the [contribution workflow](#github-workflow) to create a new pull request.
When creating pull request:
1. Please follow [the pull request template](./.github/PULL_REQUEST_TEMPLATE.md).
2. Please make sure the PR has a corresponding issue.
3. If your PR contains large changes, e.g. component refactor or new components, please write detailed documents
about its design and usage.
4. Note that a single PR should not be too large. If heavy changes are required, it's better to separate the changes
to a few individual PRs.
5. After creating a PR, one or more reviewers will be assigned to the pull request.
6. Before merging a PR, squash any fix review feedback, typo, merged, and rebased sorts of commits.
The final commit message should be clear and concise.
### Code review guidance
Our PMC will rotate reviewing the code to make sure all the PR will be reviewed timely and by at least one committer. If we aren't doing our job (sometimes we drop things). And as always, we welcome volunteers for code review.
Some principles:
- Readability - Important code should be well-documented. API should have Javadoc. Code style should be complied with the existing one.
- Elegance: New functions, classes or components should be well designed.
- Testability - 80% of the new code should be covered by unit test cases.
- Maintainability - Comply with our [PMD spec](style/codeStyle.xml), and 3-month-frequency update should be maintained at least.