> For the complete documentation index, see [llms.txt](https://berinis-organization.gitbook.io/ono/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://berinis-organization.gitbook.io/ono/development/development-and-merge-request-policy.md).

# Development & Merge Request Policy

## 🚀 Ono Coin Development & Merge Request Policy

Welcome to the **Ono Coin** development community!\
To ensure the stability, security, and high quality of the project, all contributions must follow this **Development & Merge Request Policy**. Please read this carefully before submitting a merge request (MR).

***

### 📜 General Principles

1. **Security First**:\
   Blockchain software is **mission-critical**. Contributions **must not** introduce vulnerabilities or weaken existing security measures.
2. **Minimalism and Performance**:\
   Ono Coin is designed to be **lightweight and efficient**. Avoid unnecessary libraries or bloated dependencies. All code should be **optimized** for performance and resource usage.
3. **Backward Compatibility**:\
   Avoid breaking changes to public APIs, protocols, or storage formats unless explicitly approved by core maintainers via a proposal process.

***

### 🔀 Merge Request (MR) Process

#### 1. Fork and Branching

* **Fork** the main repository.
* Create a **feature branch** from the `dev` branch:

  ```
  git checkout dev
  git checkout -b feature/your-feature-name
  ```

***

#### 2. Coding Standards

* Follow **consistent code style** (see `.editorconfig` and `.eslintrc` if available).
* **Document** all public methods and new logic using **JSDoc**.
* Add **unit tests** for any new functionality.
* **Type-safe** development is preferred — use JSDoc for type definitions.
* **Keep commits clean and atomic**:
  * One feature/bugfix per commit.
  * Good commit messages (see below).

***

#### 3. Commit Message Guidelines

Each commit message should:

* Be **clear and descriptive**.
* Follow this format:

  ```
  [Type] Short description (max 72 chars)

  Longer description if necessary explaining rationale.
  Issue/PR Reference: #123
  ```
* Example:

  ```
  [Fix] Correct transaction fee calculation

  Fixed an edge case when fee exceeds max limit in large transactions.
  Issue: #42
  ```

**Types**:

* `[Fix]` — Bug fix.
* `[Feat]` — New feature.
* `[Refactor]` — Code refactoring without changing functionality.
* `[Docs]` — Documentation update.
* `[Chore]` — Maintenance (e.g., tests, configs).

***

#### 4. Merge Request Requirements

Every MR **must** include:

* **Detailed description** of the change.
* Reason for the change (linked to issue if applicable).
* Tests that validate the new code.
* Impact analysis (if breaking, performance-related, etc.).
* Any **security considerations**.

***

#### 5. Review and Approval

* All MRs require **at least 1 approval from a core maintainer**.
* Large changes may require **community discussion and consensus** via GitHub Discussions or Issues before approval.
* **Security-related changes** will undergo a **deep review**, possibly with independent experts.

***

### ✅ Best Practices for Contributors

* **Discuss major features first** via issues before developing.
* Keep PRs **small and focused** — easier to review and merge.
* **Rebase** your branch before creating an MR to avoid conflicts:

  ```
  git fetch origin
  git rebase origin/dev
  ```
* **Test locally** before pushing:

  ```
  npm test
  ```

***

### 🚫 Prohibited Contributions

* **Obfuscated code** or **minified files**.
* Proprietary or **licensed third-party** code that is incompatible with Ono Coin's license.
* Unnecessary dependencies or unreviewed cryptographic implementations.
* Changes that **bypass security mechanisms** (signature validation, transaction integrity, etc.).

***

### 🛡️ Security Guidelines

* All cryptographic operations **must use established, audited libraries**.
* Never store or expose **private keys** within the system.
* Review and validate **transaction logic** to prevent double-spending, overflow/underflow issues.

***

### 📅 Release Cycle

* Active development happens in the `dev` branch.
* Stable versions are merged into `main` only after review and testing.
* All releases are **versioned and tagged** following **Semantic Versioning (SemVer)**.

***

### 🙌 Community and Support

* Join the GitHub Discussions or Discord server for ongoing conversations.
* Submit issues for bugs or improvement suggestions.
* Respectful and constructive communication is **mandatory**.

***

### 📝 License Compliance

By submitting a merge request, you agree that your contributions will be released under the same license as the Ono Coin project (MIT, GPL, or as specified).

***

### 💎 Final Note

Thank you for contributing to **Ono Coin**! Together, we are building a decentralized and efficient blockchain for everyone. Let's keep it secure, fast, and open-source! 🚀