First off, thanks for being here.
OverLab is built by people like you — rebels, builders, and breakers who give a damn.
Whether you’re fixing a typo, tackling a bug, or shipping a shiny new feature, you make this community what it is.
Please take a moment to read this guide. It’s not here to scare you off — it’s here to make sure we build great stuff, together.
Every pull request must be backed by an issue.
This isn’t bureaucracy — it’s communication.
- Open a detailed issue describing what you want to do.
- Include concrete code examples if possible.
- Wait for a maintainer to acknowledge it before you start coding.
This saves you from spending hours on something that might not fit the project’s direction.
When you’re ready to submit, use the standard PR template.
It’s designed to capture all the information reviewers need — no guesswork.
| Area | Requirement |
|---|---|
| Code Quality | Clean, simple, and self‑documenting. Follow DRY (Don’t Repeat Yourself) and KISS (Keep It Simple, Stupid). |
| Malicious Code | Absolutely zero tolerance. Any PR found to contain intentional backdoors, data exfiltration, or harmful logic will be rejected and the contributor banned. |
| Cross‑Platform | Must work on all platforms and architectures listed in the repository’s README. |
| Testing | Not mandatory, but PRs with tests get priority review. If you add tests, they must be meaningful. |
| Benchmarking | Required for any performance‑sensitive change. Provide before/after metrics (see below). |
| Backward Compatibility | Breaking changes require an RFC (see “Major & Minor Changes”). |
When submitting a change that may affect performance, measure these metrics before and after:
- ✅ Memory usage (peak / average)
- ✅ Execution speed (operations per second, total runtime)
- ✅ Startup time
- ✅ Code size (lines of code, bundle size)
- ✅ Output file size (binary, distribution, etc.)
- ✅ Bugs, warnings, errors (compiler/linter output)
- ✅ Optimization hints (e.g., compiler remarks, clippy lints)
- ✅ Number of files / directories (if structural changes are involved)
Include a summary table in your PR comment.
If you’re unsure how to benchmark, ask in the issue — we’ll help.
If your change introduces a breaking change (MAJOR), you must submit an RFC before writing code.
RFC = Request for Comments
- Write a clear description of the change, its motivation, and its impact.
- Send it to: overlab.group@gmail.com
Subject:[RFC] Project Name - MAJOR - Wait for the core team to review and respond (usually within 5 business days).
Minor features (backward‑compatible) do not require an RFC — just open an issue and discuss it with the community.
But if you’re unsure whether your change is MAJOR or MINOR, ask first in the issue.
- Readability > cleverness – Your code will be read more often than it’s written.
- Consistency – Follow the existing style of the project. We don’t enforce a single “perfect” style, but please don’t mix tabs and spaces.
- Comments – Explain why, not what. The code should already say what it does.
- Commit messages – Use clear, concise messages.
Conventional Commits are welcome but not mandatory.
- At least one code owner (
@JavadIntegeror@OverLab-Group/overlab-dev-team) must approve your PR. - Reviews are constructive, not personal. We’re all here to learn.
- If changes are requested, don’t take it personally — iterate and push again.
We strive to be a welcoming, inclusive space.
By contributing, you agree to abide by our Code of Conduct.
You’re not just writing code — you’re shaping the future of OverLab.
Every issue, every PR, every line matters.
Welcome to the movement. 🚀