Merge pull request #1796 from cosmos/rigel/contributing
R4R: Contributing Guidelines advocate early discussion b4 coding
This commit is contained in:
Rigel
GitHub
commit
63f70cb414
|
|
@ -4,13 +4,14 @@ v Before smashing the submit button please review the checkboxes.
|
|||
v If a checkbox is n/a - please still include it but + a little note why
|
||||
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
|
||||
|
||||
* [ ] Updated all relevant documentation (`docs/`)
|
||||
* [ ] Updated all relevant code comments
|
||||
* [ ] Wrote tests
|
||||
* [ ] Added entries in `PENDING.md`
|
||||
* [ ] Updated `cmd/gaia` and `examples/`
|
||||
- [ ] Linked to github-issue with discussion and accepted design
|
||||
- [ ] Updated all relevant documentation (`docs/`)
|
||||
- [ ] Updated all relevant code comments
|
||||
- [ ] Wrote tests
|
||||
- [ ] Added entries in `PENDING.md`
|
||||
- [ ] Updated `cmd/gaia` and `examples/`
|
||||
___________________________________
|
||||
For Admin Use:
|
||||
* [ ] Added appropriate labels to PR (ex. wip, ready-for-review, docs)
|
||||
* [ ] Reviewers Assigned
|
||||
* [ ] Squashed all commits, uses message "Merge pull request #XYZ: [title]" ([coding standards](https://github.com/tendermint/coding/blob/master/README.md#merging-a-pr))
|
||||
- [ ] Added appropriate labels to PR (ex. wip, ready-for-review, docs)
|
||||
- [ ] Reviewers Assigned
|
||||
- [ ] Squashed all commits, uses message "Merge pull request #XYZ: [title]" ([coding standards](https://github.com/tendermint/coding/blob/master/README.md#merging-a-pr))
|
||||
|
|
|
|||
110
CONTRIBUTING.md
110
CONTRIBUTING.md
|
|
@ -1,18 +1,52 @@
|
|||
# Contributing
|
||||
|
||||
Thank you for considering making contributions to Cosmos-SDK and related repositories! Start by taking a look at this [coding repo](https://github.com/tendermint/coding) for overall information on repository workflow and standards. Note, we use `make get_dev_tools` and `make update_dev_tools` for installing the linting tools.
|
||||
Thank you for considering making contributions to Cosmos-SDK and related
|
||||
repositories!
|
||||
|
||||
Please follow standard github best practices: fork the repo, branch from the tip of develop, make some commits, and submit a pull request to develop. See the [open issues](https://github.com/cosmos/cosmos-sdk/issues) for things we need help with!
|
||||
Contributing to this repo can mean many things such as participated in
|
||||
discussion or proposing code changes. To ensure a smooth workflow for all
|
||||
contributors, the general procedure for contributing has been established:
|
||||
|
||||
Please make sure to use `gofmt` before every commit - the easiest way to do this is have your editor run it for you upon saving a file. Additionally please ensure that your code is lint compliant by running `make lint`
|
||||
1. either [open](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or
|
||||
[find](https://github.com/cosmos/cosmos-sdk/issues) an issue you'd like to help with,
|
||||
2. participate in thoughtful discussion on that issue,
|
||||
3. if you would then like to contribute code:
|
||||
1. if a the issue is a proposal, ensure that the proposal has been accepted,
|
||||
2. ensure that nobody else has already begun working on this issue, if they have
|
||||
make sure to contact them to collaborate,
|
||||
3. if nobody has been assigned the issue and you would like to work on it
|
||||
make a comment on the issue to inform the community of your intentions
|
||||
to begin work,
|
||||
4. follow standard github best practices: fork the repo, branch from the
|
||||
tip of `develop`, make some commits, and submit a PR to `develop`,
|
||||
5. include `WIP:` in the PR-title to and submit your PR early, even if it's
|
||||
incomplete, this indicates to the community you're working on something and
|
||||
allows them to provide comments early in the development process. When the code
|
||||
is complete it can be marked as ready-for-review by replacing `WIP:` with
|
||||
`R4R:` in the PR-title.
|
||||
|
||||
Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
|
||||
Note that for very small or blatantly obvious problems (such as typos) it is
|
||||
not required to an open issue to submit a PR, but be aware that for more complex
|
||||
problems/features, if a PR is opened before an adequate design discussion has
|
||||
taken place in a github issue, that PR runs a high likelihood of being rejected.
|
||||
|
||||
Take a peek at our [coding repo](https://github.com/tendermint/coding) for
|
||||
overall information on repository workflow and standards. Note, we use `make
|
||||
get_dev_tools` and `make update_dev_tools` for installing the linting tools.
|
||||
|
||||
Other notes:
|
||||
- Looking for a good place to start contributing? How about checking out some
|
||||
[good first
|
||||
issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
|
||||
- Please make sure to use `gofmt` before every commit - the easiest way to do
|
||||
this is have your editor run it for you upon saving a file. Additionally
|
||||
please ensure that your code is lint compliant by running `make lint`
|
||||
|
||||
## Pull Requests
|
||||
|
||||
To accommodate review process we suggest that PRs are catagorically broken up.
|
||||
To accommodate review process we suggest that PRs are categorically broken up.
|
||||
Ideally each PR addresses only a single issue. Additionally, as much as possible
|
||||
code refactoring and cleanup should be submitted as a seperate PRs from bugfixes/feature-additions.
|
||||
code refactoring and cleanup should be submitted as a separate PRs from bugfixes/feature-additions.
|
||||
|
||||
## Forking
|
||||
|
||||
|
|
@ -24,10 +58,10 @@ Instead, we use `git remote` to add the fork as a new remote for the original re
|
|||
|
||||
For instance, to create a fork and work on a branch of it, I would:
|
||||
|
||||
* Create the fork on github, using the fork button.
|
||||
* Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/cosmos/cosmos-sdk`)
|
||||
* `git remote rename origin upstream`
|
||||
* `git remote add origin git@github.com:ebuchman/basecoin.git`
|
||||
- Create the fork on github, using the fork button.
|
||||
- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/cosmos/cosmos-sdk`)
|
||||
- `git remote rename origin upstream`
|
||||
- `git remote add origin git@github.com:ebuchman/basecoin.git`
|
||||
|
||||
Now `origin` refers to my fork and `upstream` refers to the Cosmos-SDK version.
|
||||
So I can `git push -u origin master` to update my fork, and make pull requests to Cosmos-SDK from there.
|
||||
|
|
@ -35,8 +69,8 @@ Of course, replace `ebuchman` with your git handle.
|
|||
|
||||
To pull in updates from the origin repo, run
|
||||
|
||||
* `git fetch upstream`
|
||||
* `git rebase upstream/master` (or whatever branch you want)
|
||||
- `git fetch upstream`
|
||||
- `git rebase upstream/master` (or whatever branch you want)
|
||||
|
||||
Please don't make Pull Requests to `master`.
|
||||
|
||||
|
|
@ -100,35 +134,35 @@ Libraries need not follow the model strictly, but would be wise to.
|
|||
The SDK utilizes [semantic versioning](https://semver.org/).
|
||||
|
||||
### Development Procedure:
|
||||
- the latest state of development is on `develop`
|
||||
- `develop` must never fail `make test` or `make test_cli`
|
||||
- `develop` should not fail `make test_lint`
|
||||
- no --force onto `develop` (except when reverting a broken commit, which should seldom happen)
|
||||
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
|
||||
- before submitting a pull request, begin `git rebase` on top of `develop`
|
||||
- the latest state of development is on `develop`
|
||||
- `develop` must never fail `make test` or `make test_cli`
|
||||
- `develop` should not fail `make test_lint`
|
||||
- no --force onto `develop` (except when reverting a broken commit, which should seldom happen)
|
||||
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
|
||||
- before submitting a pull request, begin `git rebase` on top of `develop`
|
||||
|
||||
### Pull Merge Procedure:
|
||||
- ensure pull branch is rebased on develop
|
||||
- run `make test` and `make test_cli` to ensure that all tests pass
|
||||
- merge pull request
|
||||
- push master may request that pull requests be rebased on top of `unstable`
|
||||
- ensure pull branch is rebased on develop
|
||||
- run `make test` and `make test_cli` to ensure that all tests pass
|
||||
- merge pull request
|
||||
- push master may request that pull requests be rebased on top of `unstable`
|
||||
|
||||
### Release Procedure:
|
||||
- start on `develop`
|
||||
- prepare changelog/release issue
|
||||
- bump versions
|
||||
- push to release-vX.X.X to run CI
|
||||
- merge to master
|
||||
- merge master back to develop
|
||||
- start on `develop`
|
||||
- prepare changelog/release issue
|
||||
- bump versions
|
||||
- push to release-vX.X.X to run CI
|
||||
- merge to master
|
||||
- merge master back to develop
|
||||
|
||||
### Hotfix Procedure:
|
||||
- start on `master`
|
||||
- checkout a new branch named hotfix-vX.X.X
|
||||
- make the required changes
|
||||
- these changes should be small and an absolute necessity
|
||||
- add a note to CHANGELOG.md
|
||||
- bump versions
|
||||
- push to hotfix-vX.X.X to run the extended integration tests on the CI
|
||||
- merge hotfix-vX.X.X to master
|
||||
- merge hotfix-vX.X.X to develop
|
||||
- delete the hotfix-vX.X.X branch
|
||||
- start on `master`
|
||||
- checkout a new branch named hotfix-vX.X.X
|
||||
- make the required changes
|
||||
- these changes should be small and an absolute necessity
|
||||
- add a note to CHANGELOG.md
|
||||
- bump versions
|
||||
- push to hotfix-vX.X.X to run the extended integration tests on the CI
|
||||
- merge hotfix-vX.X.X to master
|
||||
- merge hotfix-vX.X.X to develop
|
||||
- delete the hotfix-vX.X.X branch
|
||||
|
|
|
|||
Loading…
Reference in New Issue