Update issue templates and CONTRIBUTING.md (#345)

* Update issue templates and CONTRIBUTING.md

* Reflect review input

* few edits

Co-authored-by: Philippe Laferriere <[email protected]>

Author: Farhad-Shabani

.github/ISSUE_TEMPLATE/bug-report.md

@@ -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 -->

.github/ISSUE_TEMPLATE/feature-request.md

@@ -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 -->

.github/ISSUE_TEMPLATE/process-improvement.md

@@ -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? -->

.github/ISSUE_TEMPLATE/question.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,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
@@ -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 [email protected]:<location of fork>
+- `git remote add origin [email protected]:<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
@@ -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
@@ -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
@@ -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:
@@ -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/