diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index c5534cb18..6feff39e7 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -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)) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index de349501c..7b7ad81fd 100644 --- a/CONTRIBUTING.md +++ b/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