Triage a GitHub issue

Triage answers three questions in order: is it real, is it new, and how urgent is it. Labels and assignees come last. Applying labels without answering the first three is filing, not triage.

1. Read it as written

Fetch the issue and its comments. Separate what the reporter observed from what they concluded. "The API returns 500 when I pass an empty array" is an observation. "The validation layer is broken" is a conclusion, and it is frequently wrong even when the observation is right. Triage the observation.

Note what is missing: version, environment, reproduction steps, actual vs expected. You need these to judge severity, but ask for them only after step 2, most issues that look under-specified turn out to be duplicates of a well-specified one.

2. Search for duplicates before anything else

This is the step that gets skipped and the one that saves the most work.

Search the issue's distinctive terms, an error string, a function name, a status code, rather than its title. Titles describe symptoms in the reporter's words; error text is stable across reporters. Search closed issues too: a bug closed as fixed and reported again means a regression, which is a different and more urgent finding than a new bug.

When you find a duplicate, comment linking both directions and close the newer one, unless the newer report contains a better reproduction, in which case close the older and carry the good repro forward.

3. Reproduce, or say plainly that you did not

If the repo is checked out and the issue has steps, run them. Record the result in a comment: what you ran, what happened, on what version.

If you cannot reproduce, say which specific step failed and what you saw instead. Never label something cannot-reproduce on the strength of not having tried, an unreproduced bug that gets closed and refiled three times costs more than the ten minutes of trying.

4. Judge severity on impact, not volume