Contributions and pull requests are welcome. Before posting, search existing Issues and Discussions to avoid duplicates and choose the appropriate channel below.
Maintainer time is limited. Reports that do not follow these guidelines may be closed or moved without investigation.
Use the repository's GitHub Issues for:
- Actionable bugs: observable behavior where the affected project or component does not behave as documented or intended, produces an error or crash, or behaves inconsistently under equivalent conditions. A difference in preference or desired behavior is not by itself a bug.
- Well-defined feature requests: a specific problem, use case, and proposed outcome whose scope can be evaluated and acted upon.
A report may still be valid when the cause is uncertain. What matters is that the unexpected behavior is concrete and reproducible enough to investigate.
Use the repository's GitHub Discussions for:
- Questions about using or building the project.
- Troubleshooting where a project defect has not been established.
- Early-stage, exploratory, or broad ideas.
- Proposals that need feedback before their scope or desired behavior is clear.
Starting even a defined feature request in the Ideas discussion category is encouraged, especially when the change is large, affects existing behavior, or has significant design tradeoffs. Once the proposal is concrete and a maintainer agrees it is suitable, it may be tracked as an Issue.
Issues are not a support forum. Repeatedly opening questions as Issues after being redirected may be treated as disruptive behavior under the Code of Conduct.
A bug report must contain enough information for another person to understand and investigate the problem. Include, as applicable:
- A concise description of the observed and expected behavior.
- Exact reproduction steps and the smallest reproducible example.
- Project version, commit, or build date.
- Operating system, architecture, compiler, graphics backend, and other relevant environment details.
- Complete logs, error messages, crash stack traces, or sanitizer reports as text when available.
- Screenshots or a short recording for visual or interaction problems.
- Whether the problem is reproducible and whether it previously worked.
Remove passwords, tokens, private files, and other sensitive information before posting. Do not replace essential evidence with vague summaries such as "it doesn't work" or "it crashes sometimes."
Maintainers may request additional information or ask the reporter to test a change. If requested information cannot be provided, explain why and share the best alternative evidence available. Reports may be closed when there is not enough information to investigate or when the reporter does not respond or provide requested information within a reasonable time, or does not cooperate in a meaningful way. They can be reconsidered when the missing information becomes available.
A feature request should explain the concrete problem or use case, who benefits, the desired behavior, relevant constraints and alternatives, and which project or component it affects.
A request is not a commitment that the feature will be implemented. Maintainers may decline requests that do not fit the project's scope, priorities, design, or maintenance capacity.
Pull requests for bug fixes, features, documentation, tests, and other project improvements are welcome. Keep each pull request focused, explain the problem and the chosen solution, follow the existing code style, and include relevant tests or clear verification steps when practical. For large or potentially breaking changes, start a Discussion before investing substantial work.
Opening a pull request does not guarantee acceptance. Changes must fit the project's scope and technical direction, and may require revision after review.
Do not use automated systems to create Issues or Discussions without meaningful human review. Bulk-generated, unattended, or unverified submissions are not welcome and may be treated as spam. If AI tools help prepare a post, the person submitting it must verify its accuracy, ensure it follows these guidelines, and take responsibility for its content and any follow-up.
Automated or AI-assisted pull requests are welcome when they provide clear value and are reviewed by the submitter. They are evaluated by the same quality, verification, and responsiveness standards as any other contribution.
Open one report per independent problem. Do not split one problem across several Issues, repost closed content, or open a rapid batch of reports before maintainers can triage them. If you have found many possible problems, start a Discussion or prioritize the clearest and best-supported reports first.
Repeated vague, duplicative, unsupported, or noncompliant reports may be closed, and continued behavior may lead to interaction limits or a block. These standards apply to everyone; contribution history may help maintainers assess good-faith participation but does not exempt anyone from the rules.
Do not use alternate accounts to evade moderation or posting controls. Account evasion may result in an immediate block without an additional warning.
All participation is subject to the Code of Conduct.