Community Triage

Community Triage

Handle community issues and PRs with respect, evidence, and firm scope discipline.

This skill exists to protect maintainer time, avoid speculative changes, and preserve the project's intended boundary.

Project Boundary

• Wyoming OpenAI is an OpenAI-compatible proxy/middleware.
• Treat OpenAI-compatible request/response behavior as the primary contract.
• Existing backend enum/autodetection exceptions are compatibility shims, not a license to support arbitrary provider-specific transports, routes, or schemas.
• Do not expand scope to custom endpoints such as /tts, provider-specific stream=true semantics, or bespoke response formats unless the maintainer explicitly chooses to widen scope.

Goals

• Be helpful without overcommitting.
• Separate local defects from upstream limitations and unsupported integrations.
• Prefer minimal actionable next steps: fix locally, request reproduction details, route upstream, or close with clear reasoning.
• Maintain a respectful tone even when issue quality is low.

Default Posture

• Assume good faith.
• Do not mirror vague or incorrect technical framing.
• Translate the report into the actual technical question the project can answer.
• Use evidence from code, tests, docs, and upstream behavior before concluding.
• Do not let conversation momentum expand the project's scope by accident.

Triage Workflow

1. Classify the thread.
2. Identify the supported surface.
3. Gather evidence.
4. Decide ownership.
5. Respond with a clear outcome.

1. Classify the thread

Choose the closest category:

• bug/regression on a supported surface
• feature request inside scope
• feature request outside scope
• support question or configuration issue
• upstream compatibility issue
• low-fidelity report with insufficient reproduction
• community PR

2. Identify the supported surface

Pin down the exact surface before deciding anything:

• endpoint path
• Wyoming event flow
• CLI/config flag
• backend compatibility path
• testable request/response behavior

Explicitly determine whether the report concerns an OpenAI-compatible path or instead depends on a custom provider API.

3. Gather evidence

Use the repo and upstream references, not assumptions.

• inspect the relevant implementation and tests in this repo
• read linked upstream docs/issues/PRs, not just their titles or summaries
• verify the exact route, request schema, and response transport involved
• distinguish between "supports streaming somewhere" and "streams on the exact supported integration surface used here"

4. Decide ownership

Assign the issue to one bucket:

• local defect in this repo
• upstream defect or limitation
• out-of-scope custom integration request
• uncertain because key evidence is still missing

5. Respond with a clear outcome

Pick one outcome and be explicit:

• implement/fix
• ask for concrete reproduction details
• route upstream
• close politely with scope reasoning

Evidence Standard

Treat these as strong evidence:

• code paths
• tests
• official docs
• concrete reproductions
• exact request/response behavior
• linked upstream implementation details

Treat these as weak evidence:

• issue titles
• second-hand descriptions
• marketing claims
• "OpenAI-compatible" labels without route-level confirmation
• "supports streaming" claims without transport details

Do not conclude a behavior is supported just because a provider advertises compatibility. Confirm the specific surface this project actually uses.

Minimum Missing Details To Request

When the report is ambiguous, ask for only what is necessary to decide ownership.

Good examples:

• exact endpoint path
• sample request/response behavior
• provider or server project link
• version or commit
• relevant logs
• minimal reproduction steps

Do not start by asking for everything. Ask for the smallest missing fact that would change the decision.

Low-Fidelity Issues

When a report is vague, technically confused, or incomplete:

• extract the likely underlying question
• ask at most a small number of precise follow-ups
• request only the missing details needed to decide whether this repo owns the problem
• avoid speculative fixes or speculative roadmap commitments

If the issue remains unsupported by evidence after reasonable follow-up, close it politely rather than leaving it open indefinitely.

Scope Guardrails

• Do not add support for provider-specific custom endpoints when an OpenAI-compatible endpoint already exists but behaves differently.
• Do not treat "it works in another server's /tts route" as evidence that this repo should adopt that route.
• Do not add speculative compatibility code for transports that are not part of the supported contract.
• Do not widen the compatibility layer beyond small, clearly bounded backend exceptions without explicit maintainer intent.
• Do not add new provider-specific autodetection probes (custom /health, /readyz, /test, or similar routes) when explicit backend configuration or the OpenAI-compatible surface itself can identify the backend. A new provider-specific route is justifiable only when it fills a gap the OpenAI spec does not cover (for example voice listing); pure identity probes do not meet that bar.
• Prefer "upstream should make their OpenAI-compatible surface behave correctly" over "this proxy should learn every custom dialect."

Boundary Example

If an upstream Chatterbox server streams on a custom /tts endpoint but buffers on its OpenAI-compatible /v1/audio/speech endpoint:

• do not add /tts support here
• do not reopen scope just because the custom route exists
• explain that Wyoming OpenAI targets the OpenAI-compatible surface
• route streaming complaints about /v1/audio/speech upstream unless there is evidence this repo mishandles a truly incremental OpenAI-compatible response

Issue Decision Matrix

Keep Open Or Fix Here

Keep the issue open or fix it when:

• there is evidence the failure occurs on a supported OpenAI-compatible surface used by this repo
• the behavior regressed from prior repo behavior
• a minimal fix exists without expanding scope
• the report includes enough detail to reproduce or the code clearly shows a defect

Ask For Details

Ask for more detail when:

• the failure might be in this repo, but one or two key facts are missing
• the report mixes supported and unsupported surfaces and needs disambiguation
• an upstream implementation claims compatibility but the actual route/response behavior is still unknown

Route Upstream

Route upstream when:

• the failing behavior lives in another project's OpenAI-compatible server or provider
• the linked implementation buffers where true streaming is expected
• the only path that provides the requested capability is a custom upstream endpoint outside this repo's target contract