A public project receives fifty messages: a reproducible defect, an unclear complaint, three copies of the same request, and several interesting suggestions. Treating them all as equally ready tasks makes the backlog difficult to use. Issue triage is the work of understanding what has arrived before deciding what to do with it.
A basic intake decision is whether a report is actionable or needs more information. A detailed description of a reproducible fault can move toward investigation; “it doesn't work” needs clarification first. Triage adds judgments about category, urgency, and the next appropriate step.
Intake is a conversation
A maintainer might ask which version someone used, combine duplicate reports, or identify a suggestion that belongs in a wider design discussion. That makes the reporter's knowledge more useful and protects the team's attention from repeatedly investigating the same uncertainty.
The process can also become an unwelcoming gate. An experienced contributor may know exactly which details to supply, while a newcomer with a serious problem may not. A useful clarification explains what information would help rather than simply closing the report for failing a template.
Triage does not promise that every valid issue will be fixed. It creates an intelligible status and a path into the work. That distinction helps people understand the difference between being heard, having a problem accepted, and receiving a commitment to solve it.