TQEC Contributor Guidelines

These guidelines help ensure our codebase remains consistent, readable, and maintainable.

Getting Started

Check Existing Issues: Browse the open issues folder to see if a similar contribution has been suggested or is in progress.
Open a New Issue: If you have a new idea or bug fix, open a new issue to discuss it with the project maintainers.
Fork the Repository: Fork the repository under your own account, so you can work on your changes in your own space.

Branching: Create a new branch with a descriptive name (e.g., recolor-qubits or bugfix-login-blocker)
Coding Style: We use eslint and pylint.
Use clear, descriptive variable and function names. camelCase is generally preferred in JavaScript, while snake_case is in Python.

Update relevant documentation when new features are added. Offer to author wikis.
Add inline code comments to explain complex logic.

Write clear, concise descriptions of the problem your pull request solves. Do not duplicate existing functionality in the main branch.
Pull requests should generally be less than 500 lines long. While there isn't a hard cap, please acknowledge the time and attention required to review your changes.
Provide a detailed description of your changes.
All code must follow the style guide specified in .eslintrc or .pylintrc.
Submit pull requests from your personal fork and development branch to the project's main branch.
Reference the related issue. (If it doesn't already exist, please submit one)
Organization members should assign their active tasks to an existing project and milestone; if you're contributing regularly, you can be made a member if desired.

🛠️ Unit/integration testing and CI/CD infrastructure is under construction, and adding tests helps ensure your code works as advertised.

Communication: Be courteous and responsive in discussions on issues and pull requests.
Licensing: Ensure your contributions are compatible with the Apache 2.0 license.

Thank you for contributing to TQEC!