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

Jump to bottom

chore: simplify GitHub issue labeling #925

Merged
merged 1 commit into from
Oct 17, 2023
Merged

chore: simplify GitHub issue labeling #925

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
17 changes: 8 additions & 9 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,14 +75,13 @@ We welcome bug reports, feature requests, and other contributions to our project

3. **Provide detailed information**: In the issue description, clearly state the purpose of the issue and follow the guidelines of the issue template

4. A maintainer will take care of assigning the appropriate labels to your issue.
Note: A maintainer will take care of assigning the appropriate labels to your issue with the following convention:

We use the following convention for issue label names:
- (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: errors`, `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.
- Objective-level (WHY): conveys the overarching purpose or objective of the issue by labels starting with "O" like `O: security`, `O: new-feature`, etc.

- Scope-level (WHICH): specifies the part of the system that the issue pertains to and labels starting with "S" like `S: non-cosmos`, `S: no-std`, etc.

- Admin-level (HOW) includes relevant administrative considerations on how best handling the issue and labels starting with "A" like `A: help-wanted`, `A: critical`, etc.

## Pull Requests

Expand Down Expand Up @@ -256,7 +255,7 @@ Our release process is as follows:
2. Publish `ibc-derive` with `cargo publish -p ibc-derive`
4. Bump the versions of relevant crates (`ibc` and `ibc-query`) in their
`Cargo.toml` to the new version, and push these changes to the release PR.
+ If you released a new version of `ibc-derive` in step 3, make sure to update that dependency.
- If you released a new version of `ibc-derive` in step 3, make sure to update that dependency.
5. Run `cargo doc -p ibc --all-features --open` locally to double-check that all the
documentation compiles and seems up-to-date and coherent. Fix any potential
issues here and push them to the release PR.
Expand All @@ -268,7 +267,7 @@ Our release process is as follows:
10. Create a signed tag and push it to GitHub: `git tag -s -a vX.Y.Z`. In the
tag message, write the version and the link to the corresponding section of
the changelog.
+ Push the tag with `git push --tags`
- Push the tag with `git push --tags`
11. Once the tag is pushed, create a GitHub release and append
`[📖CHANGELOG](https://github.com/cosmos/ibc-rs/blob/main/CHANGELOG.md#vXYZ)`
to the release description.
Expand Down