Improve contribution documentations and add templates (#816)

* Improve contribution documentations and add templates

* Fix missing paragraph

* Reorganize check list and contributing.md

CONTRIBUTING.md

@@ -1,15 +1,61 @@
 # How to contribute
 
-We're really glad you're reading this, because we need volunteer developers to help this project come to fruition.
+Thanks for showing interest and sharing your time to contribute to this project!
+
+This guide is meant to be used as general guideline creating issues or
+pull requests. We encourage all first contributors to give this a read to avoid
+common mistakes and improve the quality of all contributions.
 
-## Submitting changes
 
-Please send a [GitHub Pull Request to Trento](https://github.com/trento-project/web/pull/new/main) with a clear list of what you've done (read more about [pull requests](http://help.github.com/pull-requests/)).
+## Opening issues
 
-Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:
+Before creating a new issue make sure you use the search functionality to confirm
+that a similar issue doesn't already exist. Next, make sure you properly label
+the issue as per our [labels](https://github.com/trento-project/web/labels)
 
+If you are reporting a `bug`, please share a file generated using the 
+`trento-support.sh` script with the following params:
+```
+# trento-support.sh --collect all --output file-tgz
 ```
-git commit -m "A brief summary of the commit
-     
-A paragraph describing what changed and its impact."
-```
+and include the output to your issue. The script should remove sensitive data
+automatically but please make sure you are not sharing anything sensible yourself.
+
+## Submitting changes
+
+### Pull Requests guideline
+
+Reviews are hard. This few points will help reduce the effort and allow us to
+merge your changes faster.
+
+1. Only touch relevant files.
+2. We have a PR template to aid you in completing the required details. Be 
+   sure to complete it and remove the non-relevant parts.
+4. Keep PRs as small as possible. When the PR gets too big, consider splitting
+   it in multiple parts. An PR should ideally be between 100 and 500 additions.
+5. Check that the tests are passing.
+6. Check that your code is not generating new warnings.
+7. Check that any dependent changes have been merged and published in downstream modules
+8. Commit history should be short and group changes that otherwise wouldn't
+   make sense on their own.
+9. Always write a clear log message for your commits. One-line messages are 
+   fine for small changes, but bigger changes should look like this:
+
+    ```
+    git commit -m "A brief summary of the commit
+    
+    A paragraph describing what changed and its impact."
+    ```
+10. Write a detailed description that gives context and explains why you are
+   creating the PR.
+11. If the PR adds functionality, please add some tests and documentation 
+    to support it.
+12. Each PR needs 1 approval to be merged. Select a reviewer in particular if
+   you are looking for specific feedback from someone.
+
+### Reviewers guideline
+1. Opinionated comments are welcome but don't expect them always to be 
+   addressed. Be ready for discussion but also open to concede.
+2. In order to avoid scope creeping, consider to propose subsequent PRs 
+   rather than requesting changes for the current PR you are reviewing.
+3. Short, concise comments with examples are the most valuable.

docs/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,37 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Installation details**
+ - Use the [trento-support.sh script](https://github.com/trento-project/helm-charts/blob/main/scripts/trento-support.sh) to generate share a file with your installation details, as follows:
+
+    `trento-support.sh` script with the following params:
+    ```
+    # trento-support.sh --collect all --output file-tgz
+    ```
+ - Include the generated file to your issue. The script should remove sensitive data
+   automatically but please make sure you are not sharing anything sensible yourself.
+
+**Additional context**
+Add any other context about the problem here.

docs/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

docs/pull_request_template.md

@@ -0,0 +1,20 @@
+# Description
+
+Please include a summary of the changes and the related issue, if it exists. 
+Also, include relevant motivation and context for this PR. List any
+dependencies that are required for this change.
+
+Fixes # (issue)
+
+## Type of change
+
+Please delete options that are not relevant.
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+## How to test this?
+
+Describe how to test the functionality or the tests that have been added.