Opening Issues

Load this skill before filing any issue in this project.

Writing style

An issue is project documentation. Follow the conventions from the prose skill: be fact-focused, direct, and concrete. No buzzwords, no fluff, no dramatic terms. State what happened or what is being proposed, not how important it is.

Be succinct

Maintainers reading the issue already know Toasty and Rust. Keep the prose high-signal: lead with the bug or proposal, then the reproducer or API sketch, then the alternatives. Skip restated background and throat-clearing. A maintainer should grasp the problem in seconds, not paragraphs.

Pick the right template

Issue templates live in .github/ISSUE_TEMPLATE/:

• bug_report.yml — incorrect or unexpected behavior. Asks what you did, what you expected, and what happened instead; the affected driver(s); the Toasty version; and a reproducer.
• feature_proposal.yml — new features, public-API changes, or anything that affects driver implementations. Requires the problem, proposed solution, alternatives considered, and a scope estimate.

Read the template before writing. Fill in every field it asks for; don't drop sections or leave placeholders. If a field does not apply, say so explicitly rather than leaving it blank.

Bug reports

Report what you observed, not why you think it happened. A bug report has five parts:

• What you did — the query or operation you ran.
• What you expected — the result you expected.
• What actually happened — the error, wrong result, or panic. Quote the exact message, generated SQL, or backtrace.
• Additional context — affected driver, Toasty version, related issues.
• A minimal reproducer — a failing test in crates/toasty-driver-integration-suite/src/tests/ is ideal; a small standalone snippet works too. This is the single most useful thing in the report.

Leave out root-cause analysis. Diagnosing the bug is the maintainer's job, and a guess at the cause sends triage down the wrong path. Describe the behavior; the reproducer shows the rest.

Feature proposals

Describe the problem before the solution. Name who is affected — Toasty users, driver implementors, or both. Sketch the user-facing API concretely; vague proposals are hard to discuss. List the alternatives you considered and why you discarded them.

Non-trivial features follow the path in CONTRIBUTING.md: discuss in an issue, land a roadmap entry and design doc, then land the implementation.

Labels

Do not apply labels when creating the issue. The templates set the initial C-* label; maintainers triage and add the rest. See docs/dev/labels.md.