Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submission and PR guidelines #849

Merged
merged 1 commit into from
May 7, 2021
Merged

Submission and PR guidelines #849

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 25 additions & 2 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,15 +62,38 @@ Other notes:
A convenience git `pre-commit` hook that runs the formatters automatically
before each commit is available in the `contrib/githooks/` directory.

## Pull Requests
## Submissions

Generally, when structuring a submission for the Cosmos ecosystem, the submission might span multiple layers
of the technology stack, including the Cosmos SDK and Tendermint dependencies.

### Structuring a submission

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 separate PRs from bugfixes/feature-additions.

In order to simplify reviewing large changes, submissions should have a created an issue
with a description of the submission, a description tracking the changes and relevant discussions,
and a checklist of changes and tasks to be done.

The issue can then be used to develop multiple well-scoped PRs that are easy to review.

The following PR structuring checklist can be used when submitting changes to the Gaia repository for review:
- [ ] Proto files: PR updating proto files. As a suggested next step, don't regenerate updated protobuf
implementations using `protgen`, since this will break existing code.
- [ ] Broken code: If `protogen` is run, a PR disabling broken code
- [ ] Validation: PR with validation of types
- [ ] Functionality: PR integrating supporting functionality
- [ ] Servers: PR for `msgserver` and `queryserver`
- [ ] CLI: PR for CLI commands
- [ ] Orchestrators: PR for any orchestrators
- [ ] Genesis: PR for genesis
- [ ] Upgrades: PR for upgrades

### Process for reviewing PRs

All PRs require two Reviews before merge (except docs changes, or variable name-changes which only require one). When reviewing PRs please use the following review explanations:
All PRs require at least one review before merge (except docs changes, or variable name-changes which only require one). When reviewing PRs please use the following review explanations:

- `LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests locally and thoroughly reviewed it.
- `Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places, you have pulled down and tested the code locally. In addition:
Expand Down