eepp/CONTRIBUTING.md

# Contributing and Community Support

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.

## Where to post

### Issues: actionable bugs and defined feature requests

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.

### Discussions: questions, support, and ideas

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](CODE_OF_CONDUCT.md).

## Bug report requirements

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.

## Feature request requirements

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

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.

## Automated and AI-assisted submissions

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.

## Posting responsibly

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](CODE_OF_CONDUCT.md).