Getting Help

A useful starting point is a small reproducible case with the installed XY version and the output environment. XY is early alpha and does not publish a general response-time or resolution SLA, so an issue is a project report rather than a promise of a fix or delivery date.

The issue tracker is the repository's public, XY-specific project channel. Do not send secrets, credentials, private datasets, or embargoed vulnerability details through a public issue.

Run this with the same interpreter that builds the failing chart:

Include whether XY came from PyPI, a Git commit, a local editable checkout, or an internal mirror. For a Git install, include the full commit SHA. “Latest” is not a version and can refer to different code by the time someone investigates.

Remove application code until the failure still occurs with a small chart:

Then add back only the option or data shape that triggers the problem. Synthetic data is preferable to redacted production data because it preserves dtype, length, missing-value, and ordering behavior without exposing sensitive rows.

A useful report includes:

• Expected behavior and actual behavior.
• The complete exception and traceback as text.
• A runnable chart constructor and the smallest synthetic input that fails.
• Data length, dtype, null count, category count, and whether x is sorted when those details are relevant.
• Output mode: notebook widget, standalone HTML, native PNG, Chromium PNG, SVG, or a framework adapter.
• Notebook host and version, or browser name and version, for display issues.
• Explicit chart width and height for blank or layout-related failures.
• chart.memory_report() for ingest-copy or large-memory reports.

Attach a screenshot when the problem is visual, but keep the code and observed values in the issue body; an image alone cannot be executed or searched.

The source documentation can describe work that has not reached the installed wheel. Before reporting an unknown argument or missing method:

1. Print xy.__version__ from the failing environment.
2. Check the Changelog and the release or commit from which the docs were built.
3. Reproduce against the version you actually intend to deploy.
4. Include both the docs URL and the installed version in the issue.

Do not work around a mismatch by importing a private module. Pin a compatible public release or, when deliberately evaluating unreleased work, pin the exact Git commit and treat it as a source-based test environment.

The repository's security policy is authoritative for supported versions, scope, and response expectations. Use its private reporting link for injection, unsafe exported HTML, native-core memory safety, dependency, or other vulnerability concerns. A crash or bad validation result with no security impact belongs in the public issue tracker; when uncertain, start privately and let the maintainers triage it.

XY does not promise a public release cadence, feature-delivery date, or general support response time. Open issues and pull requests show active work, not a commitment that a feature will ship in a particular release. The Changelog is the record of released and unreleased changes; Limitations and alpha status is the current contract boundary.

For a feature request, explain what decision or workflow is blocked, the data and output scale involved, and what an acceptable minimal contract would be. That gives maintainers more useful information than a request for parity with an entire competing library.

Contributors who want to implement a confirmed change should follow the contributing guide and discuss contract changes in an issue before investing in a large patch.