docs(contributing): establish contribution guidelines

CONTRIBUTING.md

@@ -1,24 +1,113 @@
 # Contributing to OpenGovChain
 
-First off, thank you for considering contributing to OpenGovChain. It's people like you that make this project such a great tool for transparency.
+First off, thank you for considering contributing to OpenGovChain. It's people like you that make this project a great tool for transparency.
+
+This document outlines the conventions we follow for contributions. Please read it carefully to ensure a smooth and effective collaboration.
 
 ## How Can I Contribute?
 
-### Reporting Bugs
+You can contribute in several ways:
+
+-   **Reporting Bugs:** If you find a bug, please search for existing issues before opening a new one. If no related issue exists, open a new one with a clear title, a detailed description of the bug, and steps to reproduce it.
+-   **Suggesting Enhancements:** If you have an idea for an enhancement, open an issue with the `enhancement` label. Describe the enhancement and its potential benefits.
+-   **Pull Requests:** If you want to contribute code, please follow the process described below.
+
+## Contribution Workflow
+
+Our contribution workflow is designed to be simple and effective.
+
+### 1. Fork the Repository
+
+Start by forking the repository and cloning it to your local machine.
+
+### 2. Branching Strategy
+
+All changes should be made in a feature branch. Our branch naming convention is:
+
+```
+type/short-description
+```
+
+-   **`type`**: Describes the kind of change. We use the following types:
+    -   `feat`: A new feature.
+    -   `fix`: A bug fix.
+    -   `docs`: Documentation only changes.
+    -   `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
+    -   `refactor`: A code change that neither fixes a bug nor adds a feature.
+    -   `perf`: A code change that improves performance.
+    -   `test`: Adding missing tests or correcting existing tests.
+    -   `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation.
+    -   `ci`: Changes to our CI configuration files and scripts.
+    -   `build`: Changes that affect the build system or external dependencies.
+
+-   **`short-description`**: A few words describing the change, separated by hyphens.
+
+**Examples:**
+
+```
+feat/add-new-dataset-query
+fix/incorrect-gas-estimation
+docs/update-api-documentation
+```
+
+### 3. Development
+
+-   **Code Style:** This project uses `gofmt` for code formatting. Please ensure your code is formatted before committing.
+-   **Linting:** We use `golangci-lint` for linting. Run `make lint` to check your code for issues. You can run `make lint-fix` to automatically fix some issues.
+-   **Testing:** All new features and bug fixes must be accompanied by unit tests. Run `make test` to run the test suite.
+
+### 4. Commit Message Convention
+
+We follow the **Conventional Commits** specification. Your commit messages should be structured as follows:
+
+```
+type(scope): description
+
+[optional body]
+
+[optional footer]
+```
+
+-   **`type`**: Must be one of the types listed in the branching strategy section.
+-   **`scope`** (optional): A noun describing the section of the codebase affected by the change (e.g., `x/datasets`, `app`, `docker`).
+-   **`description`**: A concise, imperative-tense description of the change.
+
+**Examples:**
+
+```
+feat(x/datasets): add support for querying datasets by owner
+```
+
+```
+fix(app): correct genesis file validation
+```
+
+```
+docs(contributing): add new contribution guidelines
+```
+
+### 5. Pull Request (PR) Process
+
+Once your changes are ready, push your branch to your fork and open a pull request to the `main` branch of the main repository.
+
+-   **PR Title:** Your PR title should follow the Conventional Commits format.
+-   **PR Description:** Use the following template for your PR description:
+
+    ```markdown
+    ## Description
+
+    A clear and concise description of the changes.
 
-If you find a bug, please ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/bettergovph/govchaind/issues). If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/bettergovph/govchaind/issues/new). Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or an **executable test case** demonstrating the expected behavior that is not occurring.
+    ## Related Issue
 
-### Suggesting Enhancements
+    Link to the issue that this PR addresses.
 
-If you have an idea for an enhancement, please open an issue with the `enhancement` label. Provide a clear description of the enhancement and why it would be beneficial.
+    ## How to Test
 
-### Pull Requests
+    Detailed steps on how to test your changes.
+    ```
 
-1.  **Fork the repository** and create your branch from `main`.
-2.  **Set up your development environment** by following the [Getting Started](./README.md#getting-started-for-developers) guide.
-3.  **Make your changes**. Ensure your code follows the existing style and conventions.
-4.  **Commit your changes** with a clear and descriptive commit message.
-5.  **Push your branch** to your fork and **open a pull request** to the `main` branch of the main repository.
+-   **CI Checks:** Your PR must pass all CI checks before it can be merged.
 
 ## Development Setup
 
@@ -28,4 +117,4 @@ Please refer to the main [README.md](./README.md) for instructions on how to set
 ./scripts/check-build-env.sh
 ```
 
-Thank you for your contribution!
+Thank you for your contribution!