Community policy

Rigorous research requires a serious standard of conduct.

Invaris Quantum is built for researchers, engineers, students, maintainers, and contributors who may disagree sharply about technical direction while still collaborating with respect, clarity, and integrity.

RespectEvidenceSafetyCreditAccountability

Why this policy exists

This Code of Conduct protects the project’s ability to do high-quality open research. Quantum compiler work involves complex assumptions, numerical methods, hardware limitations, vendor ecosystems, and academic credit. The community needs a standard that allows direct critique of ideas while preventing harassment, intimidation, bad-faith disruption, and misuse of contributor labor.

Where it applies

This policy applies in all Invaris Quantum spaces: repositories, issues, pull requests, discussions, documentation, meetings, demos, chat channels, events, email threads, review calls, and any public or private interaction connected to the project. It also applies when someone represents the project in another venue.

How contributors should work

Be precise. Critique claims, code, assumptions, data, and methods. Avoid vague dismissal when a specific technical objection is possible.

Be reproducible. When challenging a result, identify the command, benchmark, backend profile, metric, or assumption that produces the disagreement.

Be respectful. Treat contributors as collaborators, not obstacles. Directness is welcome; contempt is not.

Give credit. Acknowledge prior work, issue authors, reviewers, maintainers, students, external libraries, and data sources.

Protect newcomers. Help new contributors understand project conventions without shaming them for missing context.

Disclose limits. If a result is preliminary, simulated, hardware-specific, approximate, or not yet validated, say so clearly.

Conduct that violates the project standard

  • Harassment, threats, stalking, sustained disruption, doxxing, or unwanted contact.
  • Insults, slurs, demeaning jokes, exclusionary comments, or attacks based on identity, background, affiliation, seniority, nationality, race, ethnicity, gender, sexuality, disability, religion, age, or other personal characteristics.
  • Sexualized language or imagery, unwelcome sexual attention, or inappropriate personal comments.
  • Bad-faith review behavior, including repeatedly ignoring evidence, moving goalposts, flooding discussions, or using review to intimidate contributors.
  • Plagiarism, misattribution, hiding material dependencies, or presenting someone else’s work as your own.
  • Fabricating benchmark results, omitting known failure cases, manipulating plots, or concealing assumptions that materially change interpretation.
  • Publishing private messages, unreleased results, confidential data, credentials, private contact information, or vendor-sensitive details without permission.
  • Retaliation against anyone who reports a concern, participates in enforcement, or sets a boundary.

Standards for technical claims

Claims about performance, gate count, pulse duration, fidelity, routing overhead, calibration burden, or hardware compatibility must be tied to reproducible artifacts whenever possible. A strong claim should identify the benchmark, input circuits, backend profile, run command, result file, metric definition, and comparison baseline. Speculation is allowed when labeled as speculation. Unsupported certainty is not.

How to report a concern

Report conduct concerns privately to conduct@invarisquantum.com. Include what happened, where it happened, relevant links or screenshots, who was involved, whether the issue is ongoing, and what outcome would help. Reports may be brief; you do not need to prove intent to ask for help.

If the concern involves a maintainer, the report should be handled by a non-involved maintainer or an appointed neutral reviewer. Anyone with a conflict of interest should recuse themselves from enforcement decisions.

How maintainers respond

ClarificationPrivate reminder, public correction, or request to revise wording.
ModerationComment editing, thread locking, issue cleanup, or redirection to a structured review path.
RestrictionTemporary limits on participation, review privileges, meetings, or repository access.
RemovalPermanent ban from project spaces for severe, repeated, or dangerous conduct.

Enforcement should be proportional, documented internally, and focused on restoring safety and project integrity. Severe safety issues may require immediate action before a full review is complete.

How decisions can be reviewed

A contributor may appeal an enforcement decision by writing to the conduct address with new context, evidence of changed behavior, or a specific reason the decision was disproportionate. Appeals should be reviewed by someone not directly involved in the original incident when possible.

Policy foundation

This policy is inspired by widely used open-source community standards, adapted for a research software project where reproducibility, credit, technical disagreement, and hardware-sensitive claims need explicit treatment.