Skip to content

Commit

Permalink
Update issue templates and CONTRIBUTING.md (#345)
Browse files Browse the repository at this point in the history 
* Update issue templates and CONTRIBUTING.md

* Reflect review input

* few edits

Co-authored-by: Philippe Laferriere <plafer@protonmail.com>
  • Loading branch information
@Farhad-Shabani @plafer
Farhad-Shabani and plafer authored Jan 12, 2023
1 parent 4b29332 commit 7a7dad7
Show file tree
Hide file tree
Showing 7 changed files with 98 additions and 174 deletions.
29 changes: 7 additions & 22 deletions .github/ISSUE_TEMPLATE/bug-report.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,34 +5,19 @@ about: Create a report to help us squash bugs!
---

<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Please also ensure that this is not a duplicate issue :)
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->

## Summary of Bug
## Bug Summary

<!-- Describe the issue you're encountering -->
<!-- Provide a short description of the issue you're encountering -->

## Version

<!-- ibc-rs release version or git commit hash -->

## Steps to Reproduce

<!-- What commands should someone run to reproduce your problem? -->
<!-- Attach logs here if you have them. -->
## Details

## Acceptance Criteria
<!-- Add details needed to reproduce the issue here -->

<!-- What's the definition of "done" for this issue? -->

____

## For Admin Use
## Version

- [ ] Not duplicate issue
- [ ] Appropriate labels applied
- [ ] Appropriate milestone (priority) applied
- [ ] Appropriate contributors tagged
- [ ] Contributor assigned/self-assigned
<!-- ibc-rs release version or git commit hash -->
29 changes: 4 additions & 25 deletions .github/ISSUE_TEMPLATE/feature-request.md
View file
Original file line number Diff line number Diff line change
@@ -1,41 +1,20 @@
---
name: Feature Request
about: Create a proposal to request a feature
about: Create a proposal to request a feature!

---

<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->

## Summary
## Feature Summary

<!-- Short description of the proposed feature -->

## Problem Definition

<!-- Why do we need this feature?
What problems may be addressed by introducing this feature?
What benefits does IBC-rs stand to gain by including this feature?
Are there any disadvantages of including this feature? -->

## Proposal

<!-- Detailed description of requirements of implementation -->

## Acceptance Criteria

<!-- What's the definition of "done" for this issue? -->

____

#### For Admin Use

- [ ] Not duplicate issue
- [ ] Appropriate labels applied
- [ ] Appropriate milestone (priority) applied
- [ ] Appropriate contributors tagged
- [ ] Contributor assigned/self-assigned
<!-- Provide a full description and requirements of the feature -->
21 changes: 21 additions & 0 deletions .github/ISSUE_TEMPLATE/process-improvement.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
---
name: Process Improvement
about: Create a proposal to suggest an improvement for `ibc-rs` operations!

---

<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Please also ensure that this is not a duplicate issue :)
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->

## Improvement Summary

<!-- Short description of the proposed improvement about the projects' processes -->

## Proposal

<!-- Describe your proposal for how some process of `ibc-rs` should be improved -->
<!-- What would be the benefits if we adopted the proposal?
Are there any disadvantages? -->
30 changes: 0 additions & 30 deletions .github/ISSUE_TEMPLATE/question.md
View file

This file was deleted.

21 changes: 0 additions & 21 deletions .github/ISSUE_TEMPLATE/release-template.md
View file

This file was deleted.

25 changes: 0 additions & 25 deletions .github/ISSUE_TEMPLATE/rust-update.md
View file

This file was deleted.

117 changes: 66 additions & 51 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -60,9 +61,67 @@ 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 and follow the guidelines of the issue template

4. A maintainer will take care of assigning the appropriate labels to your issue.

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.

## 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.

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.

## Forking

If you do not have write access to the repository, your contribution should be
Expand All @@ -72,10 +131,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:<location of fork>
- `git remote add origin git@github.com:<location of fork>`

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
Expand Down Expand Up @@ -104,13 +164,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
Expand Down Expand Up @@ -149,12 +209,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 <crate>/<module>), `xxx` is the issue number, and `contributor`
top-level crate, but could be `<crate>/<module>`), `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
Expand All @@ -174,48 +234,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:
Expand Down Expand Up @@ -255,6 +273,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/

0 comments on commit 7a7dad7

Please sign in to comment.