docs: add contribution rules

.github/ISSUE_TEMPLATE/BUG_REPORT.md

@@ -0,0 +1,34 @@
+---
+name: Bug report
+about: Let us know what went wrong.
+---
+
+# Description
+
+Describe you situation in details (i.e. with the logs, screenshots, etc). \
+**Remember, it's better to add something extra than to miss something
+important.**
+
+# Expected Behavior
+
+Describe the behavior you are expecting.
+
+# Current Behavior
+
+What is the current behavior?
+
+# Steps to Reproduce
+
+Provide detailed steps for reproducing the issue.
+
+1. Step 1
+2. Step 2
+3. ...
+
+# Context
+
+Provide any relevant info about your environment.
+
+* Tool Version:
+* Operating System:
+* Shell *(i.e. bash v4, zsh, etc.)*

.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md

@@ -0,0 +1,33 @@
+---
+name: Feature request
+about: Let us know how we can make things better.
+---
+
+# Description
+
+Provide a detailed description of the feature you are requesting (e.g. text,
+charts, diagrams, etc.) \
+**Remember, it's better to add something extra than to miss something
+important.**
+
+# Use Case
+
+Describe a specific scenario or use case where this feature would be beneficial. \
+Explain why this feature is important for users or the project as a whole.
+
+# Proposed Implementation
+
+If you have any ideas or suggestions for how the feature could be implemented,
+please outline them here. \
+Include any technical details or considerations that may be relevant.
+
+# Potential Impact
+
+Discuss the potential impact of implementing this feature as you see it. \
+Consider factors such as user experience, performance, scalability, etc. \
+Also, mention any potential risks or drawbacks associated with the feature.
+
+# Additional Information
+
+Include any additional information, resources, or references that may be
+relevant to the feature request.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,23 @@
+## Description
+
+Describe your request in details. \
+**Remember, it's better to add something extra than to miss something
+important.**
+
+## Checklist
+
+> [!TIP]
+> *Remember, there is an option to create a **Draft Pull Request** if you are not ready for merging.*
+
+Check compliance with the following
+[task list](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists)
+and describe any forced non-compliances:
+
+- [ ] [Consistency standards](https://github.com/GoogleCloudPlatform/gce-rescue/blob/main/CONTRIBUTING.md#consistency-standards) have been met
+- [ ] New code complies with the [PEP8](https://peps.python.org/pep-0008/)
+- [ ] All Python tests passed after the changes
+- [ ] New changes have been tested on all supported platforms
+
+## Notes
+
+Any additional comments to make life easier for the reviewers?

CONTRIBUTING.md

@@ -26,4 +26,60 @@ information on using pull requests.
 ## Community Guidelines
 
 This project follows
-[Google's Open Source Community Guidelines](https://opensource.google/conduct/).
+[Google's Open Source Community Guidelines](https://opensource.google/conduct/).
+
+## Consistency standards
+
+### Commit message
+
+We're trying to utilise the Conventional Commits specification. Try to follow
+this unofficial agreement to enhance readability, clarity, and collaboration.
+
+https://www.conventionalcommits.org/en/v1.0.0/#specification
+
+### Branch name
+
+As well as with commit naming, there are a lot of ways to name a branches.
+Let's try to follow these great guides to organise our project:
+
+- https://dev.to/couchcamote/git-branching-name-convention-cch
+- https://dev.to/varbsan/a-simplified-convention-for-naming-branches-and-commits-in-git-il4
+
+Branch name template:
+```
+<category/reference/description-in-kebab-case>
+```
+
+- `category` distinguishes the types of activities in the branches. Options are:
+  - `feature` - for adding new features or refactoring existing code
+  - `bugfix` - for fixing an issue/bug (unplanned changes)
+  - `test` - for experimenting, PoC, etc.
+
+- `reference` points to the source of info about the purpose of this branch.
+  Current options are:
+  - `issue-123` - GitHub issue number
+  - `b-1234567` - Buganizer ID *(for now, only for Googlers)*
+  - `no-ref` - when there is no reference *(e.g. for `test` branches)*
+
+- `description-in-kebab-case` of the problem. Try to keep a balance between
+  brevity and informative.
+
+### Issue / Pull request content
+
+There are useful templates for a new issues and pull requests which will be
+offered automatically. While you're not obligated to follow them, we recommend
+that you do so in order to standardize the review process.
+
+### Code style
+
+We strive to use the standard [PEP8](https://peps.python.org/pep-0008/) document
+for our code. You can utilize various tools to check syntax compliance, such as
+[`pycodestyle`](https://pypi.org/project/pycodestyle/) *(former `pep8`)* or
+[`black`](https://pypi.org/project/black/), as well as
+[`pylint`](https://pypi.org/project/pylint/) with the standard configuration,
+which can also be extremely useful *(sometimes too much)*.
+
+Despite being one of the most important yet ambiguous sections, the message is
+as follows: \
+**Try to be as simple as possible while balancing code readability and
+efficiency.**