About The Orqus Improvement Proposal repository

Orqus - Improvement Proposals & Project Feedback

This document serves as a guide for submitting improvement proposals, reporting issues, and providing feedback for the Orqus project. Our goal is to foster an open, collaborative community where every contribution—whether a technical proposal, bug report, or feature suggestion—helps shape the future of Orqus.

Table of Contents

• 1. Introduction
• 2. Orqus Improvement Proposals (OIPs)
• 3. Project Feedback Guidelines
• 4. Submission Process
• 5. Feedback & Proposal Review Process
• 6. Code of Conduct
• 7. FAQ

1. Introduction

Orqus is committed to continuous improvement, driven by community input and technical innovation. This repository is dedicated to collecting two key types of contributions:

• Orqus Improvement Proposals (OIPs): Formal, structured proposals for significant changes to the Orqus protocol, core infrastructure, or ecosystem tools.

• Project Feedback: Bug reports, feature requests, usability suggestions, and general comments about the Orqus project, its tools, or documentation.

Whether you’re a developer, validator, user, or enthusiast, your input is valuable. We encourage all community members to participate in shaping Orqus.

2. Orqus Improvement Proposals (OIPs)

OIPs are formal documents that propose changes to the Orqus protocol, including core smart contracts, consensus mechanisms, network parameters, or ecosystem standards. OIPs are intended for significant, impactful changes that require community discussion and consensus.

2.1 OIP Types

• Core OIPs: Proposals affecting the core protocol, consensus, or security of Orqus (e.g., changes to block structure, gas mechanics, or validation rules).

• Interface OIPs: Proposals related to user interfaces, API standards, or developer tools (e.g., changes to RPC endpoints, SDK improvements).

• Process OIPs: Proposals for changes to the OIP process itself, community governance, or project management practices.

2.2 OIP Template

All OIPs must follow the standard template to ensure consistency and clarity. Use the OIP-Template.md file in this repository as a starting point. Your OIP should include:

• Title: A clear, concise title that summarizes the proposal.

• Author: Name(s) and contact information of the proposal author(s).

• Abstract: A brief (1-2 paragraph) summary of the proposal.

• Motivation: Why is this change necessary? What problem does it solve?

• Specification: A detailed description of the proposed change, including technical details, implementation steps, and compatibility considerations.

• Rationale: The reasoning behind the proposed design, including alternatives considered and why they were rejected.

• Implementation: A link to the code (if available) or a plan for implementation.

• Backward Compatibility: Whether the proposal breaks backward compatibility, and if so, how to mitigate this.

• Security Considerations: Potential security risks and how they will be addressed.

• Copyright: A copyright statement (default: MIT License).

3. Project Feedback Guidelines

Feedback is crucial for improving the Orqus project. We welcome feedback on all aspects, including but not limited to:

• Bug reports (e.g., issues with smart contracts, node software, or tools like Forge).

• Feature requests (e.g., new functionality, usability improvements).

• Documentation suggestions (e.g., missing guides, unclear explanations).

• Performance issues (e.g., slow transaction processing, high gas costs).

3.1 Bug Reports

When reporting a bug, please include the following information to help us resolve it quickly:

• A clear, descriptive title.

• Steps to reproduce the bug (include commands, code snippets, and environment details).

• Expected behavior vs. actual behavior.

• Environment details (e.g., Solidity version, Forge version, OS).

• Screenshots, logs, or error messages (if applicable).

3.2 Feature Requests

For feature requests, please explain:

• The problem the feature solves (why it’s needed).

• A detailed description of the feature.

• How the feature would benefit the Orqus community or ecosystem.

• Any potential implementation ideas (if you have them).

3.3 General Feedback

For general feedback (e.g., usability, documentation), be specific and constructive. We want to hear what’s working well and what can be improved.

4. Submission Process

Follow these steps to submit an OIP or feedback:

4.1 Submitting an OIP

1. Fork this repository.

2. Create a new file in the OIPs/ directory with the name OIP-[number]-[title].md (e.g., OIP-001-token-standard.md).

3. Use the OIP-Template.md to draft your proposal.

4. Commit your changes and open a Pull Request (PR) to the main branch.

5. The community will review your PR, and you may be asked to make revisions.

4.2 Submitting Feedback

1. Go to the Issues tab of this repository.

2. Click "New Issue" and select the appropriate template (Bug Report, Feature Request, or General Feedback).

3. Fill out the template with the required information.

4. Click "Submit New Issue" to post your feedback.

5. Feedback & Proposal Review Process

We strive to review all submissions in a timely manner. Here’s how the review process works:

5.1 OIP Review

• After submitting an OIP PR, the Orqus core team and community will review it for clarity, technical feasibility, and alignment with the project’s goals.

• Comments and suggestions will be added to the PR. The author is expected to address these comments and revise the OIP as needed.

• Once the OIP is finalized, it will be voted on by the community (details on voting will be provided in the OIP process documentation).

• If approved, the OIP will be implemented by the core team or community contributors, and the status will be updated to "Implemented."

5.2 Feedback Review

• Bug reports will be triaged by the core team to assess severity and priority.

• Feature requests will be discussed by the team to determine if they align with the project’s roadmap.

• We will respond to all feedback within 3-5 business days to confirm receipt and provide updates on next steps.

6. Code of Conduct

All contributors to this repository must adhere to the Orqus Community Code of Conduct. We expect all interactions to be respectful, inclusive, and constructive. Harassment, discrimination, or unprofessional behavior will not be tolerated.

7. FAQ

Q: What’s the difference between an OIP and a feature request?

A: OIPs are formal, structured proposals for significant changes to the protocol or core infrastructure. Feature requests are more casual suggestions for new functionality or improvements to existing tools (e.g., a new command in the CLI).

Q: Do I need to be a developer to submit an OIP or feedback?

A: No! We welcome contributions from all community members. If you’re not a developer, you can still submit feedback on usability, documentation, or general ideas. For OIPs, technical knowledge is helpful but not required—collaboration with developers is encouraged.

Q: How long does the review process take?

A: Review times vary depending on the complexity of the submission. Bug reports and simple feedback are typically reviewed within 3-5 business days. OIPs may take longer (1-2 weeks) due to the need for community discussion.

Q: Can I update my OIP or feedback after submission?

A: Yes! For OIPs, you can push updates to your PR. For feedback, you can add comments to your issue or edit the original post.

© 2026 Orqus. All rights reserved.