Issues filed on someone else's behalf

A large share of the issues in any tracker were not written by the person who saw the problem. Support relays a customer. A manager relays a stakeholder. A developer relays something a colleague mentioned in passing at standup.

Relayed issues fail differently from first-hand ones, and the usual advice about writing good bug reports does not help, because the person writing cannot answer the questions either.

What the relay drops

Three things, reliably.

The specifics. The person who saw it had an account, a record, a timestamp, a screenshot. By the time it reaches the tracker it is "a customer reported that exports are broken". The identifiers were the most valuable part and they are the first thing to evaporate, because they look like context rather than content.

The severity. Relayers systematically flatten this in both directions. An angry customer becomes a calm ticket; a passing grumble becomes an urgent one. Neither is dishonesty, it is just that tone does not survive translation, and the relayer is guessing at how much of it to carry.

The uncertainty. This is the expensive one. The original report was hedged: "I think it only happens on the big ones, but I am not sure." The relayed version states it flatly. Now a developer spends a day on large exports because the ticket said the problem was large exports, when what the ticket actually contained was one person's untested hunch, laundered into a fact by being retyped.

Not one word of that is checkable. "Customer" is not a customer, "large" is not a size, and "seems to" is doing an enormous amount of unacknowledged work.

Say who saw it and how you heard

The single most useful change is to make the relay visible instead of hiding it. A ticket that admits it is second-hand is worth more than one that quietly pretends otherwise, because the reader can calibrate.

The last line is the one nobody writes and everybody needs. Naming what you did not ask converts a gap into a task, and it stops the next reader assuming the question was asked and the answer was uninteresting.

Quote rather than summarise

Summarising is where uncertainty gets lost, because a summary has to commit. Two sentences of the original wording, pasted verbatim, carry hedges and emphasis and confusion that no paraphrase survives. They also carry the reporter's vocabulary, which is often the clue: someone calling the same thing a "report", a "download" and a "file" in one message is telling you something about where they got confused.

It is also less work than writing a good summary, which is a rare case of the better practice being the lazier one.

Keep the line open

The relayer's most valuable property is not the detail they captured. It is that they can go back and ask. A relayed ticket with no route to the original reporter is a dead end the moment the first question comes up, and the first question always comes up.

So the ticket needs a name, or a chat thread link, or a case number. Not for the record. So the developer who gets there in three days can find out which report Dana meant, without it becoming a project.

Why this is worth bothering with

The instinct is to treat relayed issues as inherently lower quality and move on. But relayed issues are how you hear about the problems affecting people who will never open a tracker, which is almost everybody who uses what you build. Filtering them out by neglect is not neutral. It quietly narrows your input to the users confident enough to file.

Better to make the relay explicit and cheap. Who saw it, in their words, what you checked, what you did not ask, and how to reach them. Five lines, no ceremony, and the ticket stops being a rumour.