diff --git a/.github/ISSUE_TEMPLATE/bug-report.md b/.github/ISSUE_TEMPLATE/bug-report.md index 785936d88..7872fa6de 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.md +++ b/.github/ISSUE_TEMPLATE/bug-report.md @@ -5,14 +5,20 @@ about: Create a report to help us squash bugs! --- -## Summary of Bug +## Bug Summary + ## Version @@ -23,16 +29,10 @@ v Please also ensure that this is not a duplicate issue :) -## Acceptance Criteria - - - ____ -## For Admin Use +### For Admin Use - [ ] Not duplicate issue - [ ] Appropriate labels applied -- [ ] Appropriate milestone (priority) applied -- [ ] Appropriate contributors tagged -- [ ] Contributor assigned/self-assigned +- [ ] Appropriate contributors assigned diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md index b2a60b2bb..df0e57cfe 100644 --- a/.github/ISSUE_TEMPLATE/feature-request.md +++ b/.github/ISSUE_TEMPLATE/feature-request.md @@ -1,41 +1,40 @@ --- name: Feature Request -about: Create a proposal to request a feature +about: Create a proposal to request a feature! --- -## Summary +## Feature Summary + -## Problem Definition +## Definition ## Proposal - -## Acceptance Criteria - - + ____ -#### For Admin Use +### For Admin Use - [ ] Not duplicate issue - [ ] Appropriate labels applied -- [ ] Appropriate milestone (priority) applied -- [ ] Appropriate contributors tagged -- [ ] Contributor assigned/self-assigned +- [ ] Appropriate contributors assigned diff --git a/.github/ISSUE_TEMPLATE/process-improvement.md b/.github/ISSUE_TEMPLATE/process-improvement.md new file mode 100644 index 000000000..f639b3bb3 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/process-improvement.md @@ -0,0 +1,40 @@ +--- +name: Process Improvement +about: Create a proposal to suggest an improvement for `ibc-rs` operations! + +--- + + + +## Improvement Summary + + + + +## Definition + + + +## Proposal + + + + + +____ + +### For Admin Use + +- [ ] Not duplicate issue +- [ ] Appropriate labels applied +- [ ] Appropriate contributors assigned diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md deleted file mode 100644 index 43f235365..000000000 --- a/.github/ISSUE_TEMPLATE/question.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -name: Process Improvement -about: For suggestions related to the process of how `ibc-rs` is shepherded. - ---- - - - -## Proposal - - - - -## Acceptance Criteria - - - -____ - -## For Admin Use - -- [ ] Not duplicate issue -- [ ] Appropriate labels applied -- [ ] Appropriate milestone (priority) applied -- [ ] Appropriate contributors tagged -- [ ] Contributor assigned/self-assigned diff --git a/.github/ISSUE_TEMPLATE/release-template.md b/.github/ISSUE_TEMPLATE/release-template.md deleted file mode 100644 index 5fe55f8f4..000000000 --- a/.github/ISSUE_TEMPLATE/release-template.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -name: New Release Request -about: Create a proposal to track the release of a new version of IBC-RS ---- - - - - -# Release IBC-RS v.X.Y.Z - -⚡ - -- [ ] Create a new release in the changelog, using [`unclog`](https://github.com/informalsystems/unclog). - - If doing a release candidate (`rc`) version, then skip the `unclog release` step. -- [ ] Bump all crate versions to the new version. -- [ ] Reassign unfinished issues of previous milestone to the next milestone. diff --git a/.github/ISSUE_TEMPLATE/rust-update.md b/.github/ISSUE_TEMPLATE/rust-update.md deleted file mode 100644 index 3eaae89a7..000000000 --- a/.github/ISSUE_TEMPLATE/rust-update.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -name: Rust version update -about: A checklist to perform to update to a new version of Rust. ---- - -# Update to Rust release 1.x.y - -🦀 - -- [ ] Update the version in `rust-toolchain.toml`. -- [ ] Run `cargo clippy --all-features --fix`, review and commit the automatic - fixes, and fix all reported lints. Try to resolve the root causes for - the lints rather than silencing them with `#[allow(...)]`. - -## Update the MSRV (optional) - -Additional steps to perform in order to make the new minimal supported -Rust version: - -- [ ] Update the `rust-version` fields in all `Cargo.toml` files. -- [ ] Update the `msrv` field in `clippy.toml` and fix all lints reported by - `cargo clippy --all-features`. -- [ ] Update the MSRV shields in `README.md` file. -- [ ] Add a `.changelog` entry to the `breaking-changes` section, - announcing the new MSRV. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index dd0a64f02..4d5f2a14f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,9 +15,10 @@ The rest of this document outlines the best practices for contributing to this repository: - [Decision Making](#decision-making) - process for agreeing to changes +- [Issues](#issues) - what makes a good issue +- [Pull Requests](#pull-requests) - what makes a good pull request - [Forking](#forking) - fork the repo to make pull requests - [Changelog](#changelog) - changes must be recorded in the changelog -- [Pull Requests](#pull-requests) - what makes a good pull request - [Releases](#releases) - how to release new version of the crates ## Decision Making @@ -60,9 +61,76 @@ that PRs will sit open for long periods of time. Each stage of the process is aimed at creating feedback cycles which align contributors and maintainers in order to ensure that: + - Contributors don’t waste their time implementing/proposing features which won’t land in `main` - Maintainers have the necessary context in order to support and review contributions +## Issues + +We welcome bug reports, feature requests, and other contributions to our project. To open an issue, please follow these guidelines: + +1. **Search existing issues**: Before opening a new issue, please search existing issues to ensure that is not a duplicates. + +2. **Provide a clear and descriptive title**: This helps others understand the nature of the issue at a glance. + +3. **Provide detailed information**: In the issue description, clearly state the purpose of the issue include as much information as possible, such as: + - Steps to reproduce the issue + - Expected behavior + - Actual behavior + - The version of the operating system and the software you are using + - Error messages or logs (if applicable) + +4. **Use appropriate labels**: Assign relevant labels to indicate: + - (WHY) The purpose or objective of this issue with Objective-level "O" labels like `O: security`, `O: new-feature`, etc. + - (WHICH) The part of the system this issue relates to using: + - External-level "E" labels if the issue fall outside the current scope of the system and is related to external dependencies or projects like `E: non-cosmos`, `E: no-std` etc. + - or "Internal-level "I" labels for anything related to the current scope of the product like `I: logic`, `I: documentation`, etc. + - (HOW) If any administrative considerations should be taken into account use Administrative-level "A" labels like `A: help-wanted`, `A: critical`, etc. + +This assist us prioritize and categorize your issue more effectively and help others and reviewers understand the type and severity of the issue. +If the issue you worked on was tagged `A: low-priority`, we'll do our best to +review it in a timely manner, but please expect longer wait times for a review +in general. If a low priority issue is important to you, please leave a comment +explaining why, and we will reprioritize it! + +## Pull Requests + +If you have write access to the ibc-rs repo, you can directly branch off of `main`. +This makes it easier for project maintainers to directly make changes to your +branch should the need arise. Otherwise, check [Forking](#forking) section for instructions + +Branch names should be prefixed with the author's name followed by a short description +of the feature, eg. `name/feature-x`. + +Pull requests are made against `main` and are squash-merged into main. + +**PRs must:** + +- make reference to an issue outlining the context +- update any relevant documentation and include tests +- add a corresponding entry in the `.changelog` directory using `unclog`, + see the [Changelog](#changelog) section for more details. + +Pull requests should aim to be small and self-contained to facilitate quick +review and merging. Larger change sets should be broken up across multiple PRs. +Commits should be concise but informative, and moderately clean. Commits will be squashed into a +single commit for the PR with all the commit messages. + +In order to help facilitate the PR review process, tag *one* person as the +reviewer of the PR. If you are unsure of who to tag, your point of contact on +the ibc-rs team is always a natural candidate; they'll make sure that the PR gets +reviewed by whomever is most appropriate to review it. + +## Responsibilities of a PR Reviewer + +If you're tagged as the reviewer of a PR, you are responsible for shepherding it +through to completion. This includes fixing issues with the PR and taking the +lead on decisions that need to be resolved in order to get the PR merged. + +If you're tagged as a reviewer on a PR that affects a part of the code base that +you are unfamiliar with, you can hand it off to someone (with their +consent) who is more appropriate to shepherd the PR through to completion. + ## Forking If you do not have write access to the repository, your contribution should be @@ -72,10 +140,11 @@ make a pull request back upstream. When forking, add your fork's URL as a new git remote in your local copy of the repo. For instance, to create a fork and work on a branch of it: + - Create the fork on GitHub, using the fork button. - `cd` to the original clone of the repo on your machine - `git remote rename origin upstream` -- `git remote add origin git@github.com: +- `git remote add origin git@github.com:` Now `origin` refers to your fork and `upstream` refers to the original version. Now `git push -u origin main` to update the fork, and make pull requests @@ -104,13 +173,13 @@ Add a `.changelog` entry to signal that a bug was fixed, without mentioning any component. ```bash -$ unclog add -i update-unclog-instructions -s bug -n 1634 -m "Update CONTRIBUTING.md for latest version of unclog" --editor vim +unclog add -i update-unclog-instructions -s bug -n 1634 -m "Update CONTRIBUTING.md for latest version of unclog" --editor vim ``` Add a .changelog entry for the `ibc` crate. ```bash -$ unclog add -c ibc -s features --id a-new-feature --issue-no 1235 -m "msg about this new-feature" --editor vim +unclog add -c ibc -s features --id a-new-feature --issue-no 1235 -m "msg about this new-feature" --editor vim ``` ### Preview unreleased changes @@ -149,12 +218,12 @@ specific release number in Changelog. Changelog entries should be formatted as follows: -``` +```md - [pkg] Some description about the change ([#xxx](https://github.com/cosmos/ibc-rs/issues/xxx)) (optional @contributor) ``` Here, `pkg` is the part of the code that changed (typically a -top-level crate, but could be /), `xxx` is the issue number, and `contributor` +top-level crate, but could be `/`), `xxx` is the issue number, and `contributor` is the author/s of the change. It's also acceptable for `xxx` to refer to the relevant pull request, but issue @@ -174,48 +243,6 @@ instance, a change to some core protocol data structure might need to be reflected both as breaking the core protocol but also breaking any APIs where core data structures are exposed. -## Pull Requests - -If you have write access to the ibc-rs repo, you can directly branch off of `main`. -This makes it easier for project maintainers to directly make changes to your -branch should the need arise. - -Branch names should be prefixed with the author's name followed by a short description -of the feature, eg. `name/feature-x`. - -Pull requests are made against `main` and are squash-merged into main. - -PRs must: -- make reference to an issue outlining the context -- update any relevant documentation and include tests -- add a corresponding entry in the `.changelog` directory using `unclog`, - see the section above for more details. - -Pull requests should aim to be small and self-contained to facilitate quick -review and merging. Larger change sets should be broken up across multiple PRs. -Commits should be concise but informative, and moderately clean. Commits will be squashed into a -single commit for the PR with all the commit messages. - -In order to help facilitate the PR review process, tag *one* person as the -reviewer of the PR. If you are unsure of who to tag, your point of contact on -the ibc-rs team is always a natural candidate; they'll make sure that the PR gets -reviewed by whomever is most appropriate to review it. - -If the issue you worked on was tagged `A: low priority`, we'll do our best to -review it in a timely manner, but please expect longer wait times for a review -in general. If a low priority issue is important to you, please leave a comment -explaining why, and we will reprioritize it! - -## Responsibilities of a PR Reviewer - -If you're tagged as the reviewer of a PR, you are responsible for shepherding it -through to completion. This includes fixing issues with the PR and taking the -lead on decisions that need to be resolved in order to get the PR merged. - -If you're tagged as a reviewer on a PR that affects a part of the code base that -you are unfamiliar with, you can hand it off to someone (with their -consent) who is more appropriate to shepherd the PR through to completion. - ## Releases Our release process is as follows: @@ -255,6 +282,3 @@ Our release process is as follows: `[📖CHANGELOG](https://github.com/cosmos/ibc-rs/blob/main/CHANGELOG.md#vXYZ)` to the release description. 11. All done! 🎉 - -[crates.io]: https://crates.io -[crates.io-security]: https://codeandbitters.com/published-crate-analysis/