Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
90 lines (59 loc) · 2.66 KB

CONTRIBUTING.md

File metadata and controls

90 lines (59 loc) · 2.66 KB

Contributing

Thank you for your interest in contributing. QuadtrixLabs projects are built from scratch, kept minimal, and designed to run locally — contributions should follow that same spirit.

Ground Rules

  • No unnecessary dependencies. If it can be written from scratch in a reasonable amount of time, write it from scratch.
  • No cloud requirements. All tools must be fully functional on a local machine.
  • Clear code over clever code. Comment your reasoning, not just what the code does.
  • Respect existing architecture. Read the project's README and any architecture notes before opening a PR.

Getting Started

  1. Fork the repository you want to contribute to.
  2. Clone your fork locally.
  3. Create a feature branch — git checkout -b feature/your-feature-name
  4. Make your changes with clear, descriptive commits.
  5. Test your changes locally before submitting.
  6. Open a Pull Request against the main branch.

Commit Style

Use short, imperative commit messages:

Add tokenizer support for BPE encoding
Fix attention mask shape mismatch in multi-head layer
Refactor CUDA kernel for memory efficiency

Avoid vague messages like fix stuff, updates, or misc changes.

Code Style

C++

  • Use snake_case for variables and functions, PascalCase for classes.
  • Prefer standard library types over raw pointers where possible.
  • Comment non-obvious logic, especially in math-heavy sections (attention, softmax, etc.).

Python

  • Follow PEP 8.
  • Use type hints where practical.
  • Keep notebooks clean — clear outputs before committing.

Issue Reporting

Before opening an issue:

  • Search existing issues to avoid duplicates.
  • Include your OS, hardware specs (especially GPU/CPU), and Python/compiler version.
  • Provide a minimal reproducible example when reporting bugs.

Use the provided issue templates for bug reports and feature requests.

What We're Looking For

  • Performance improvements to inference or training loops
  • Better hardware compatibility (CPU, GPUs)
  • Improved documentation and architecture explanations
  • Additional model architectures (implemented from scratch)
  • Testing infrastructure

What We're NOT Looking For

  • Integrations with cloud APIs or hosted inference services
  • Wrappers around existing model frameworks (we build, not wrap)
  • Unnecessary abstraction layers

License

By contributing, you agree that your contributions will be licensed under the same license as the project (MIT unless stated otherwise).

Questions? Open a discussion or reach out to @Eamon2009.