What a Long Issue Actually Contains
A long GitHub issue rarely looks like one conversation. It usually holds a bug report, a debate about the fix, a few abandoned patches, and a decision somewhere near the end. If you open it cold and try to remember everything, you will lose the thread before comment thirty. A summary is a way of compressing that structure into something a teammate can read in two minutes.
Before you compress anything, name the parts. Most long issues contain a handful of recurring ingredients, and spotting them early makes the rest of the work mechanical.
- The original report, which states the problem and often includes logs, stack traces, or screenshots.
- The clarifying questions that narrow the problem down to a single cause.
- The experiments, patches, and workarounds people tried along the way.
- The decision that the maintainers eventually reached, plus the reasons for it.
- The follow-up work that got split into separate issues or pull requests.
Sort first, write second. Once you can point at those ingredients, the summary stops being a writing task and becomes a sorting task. You are not inventing prose; you are filing each sentence where it belongs.
Set the Goal Before You Read a Single Line
A summary without a reader in mind tends to reproduce the whole issue in shorter sentences, which helps nobody. Decide what the summary is for. Maybe you are triaging and need to know whether the bug still matters. Maybe you are picking up the work and need to know which files are involved. Maybe you are preparing a release note and need to know what changed for users.
Each goal pulls different detail to the surface. Triage wants impact and reproduction steps. A handover wants the failed attempts, so you do not repeat them. Release notes want the user-visible change and nothing else. Write the goal as a single sentence at the top of your notes, and keep referring to it while you read.
If the issue is truly enormous, break the summary into layers. Write one paragraph for the whole thread, then three or four bullets for the key turns in the discussion. A reader who needs more can ask; a reader who needed less gets their time back.
A Checklist for the First Pass
The first pass is about navigation, not prose. Read the opening post and the closing comments before anything else. The beginning tells you what the problem was; the end tells you where it landed. The middle is where the details live, and you can visit it with a map already in your head.
As you skim, mark the comments that changed the direction of the thread. Those are your anchors, and the summary usually lives or dies on how well they are captured. Look for:
- A concrete reproduction that everyone agreed on.
- A hypothesis that was tested and then rejected.
- A workaround that people are still relying on.
- A maintainer decision, even a tentative one.
- Any linked pull request, commit, or follow-up issue.
Ignore repetition, sign-offs, and the three-comment exchanges where two people politely restate each other. Noise is not part of the record you need to keep. When a thread runs into hundreds of comments, a fast and inexpensive model can handle the first pass for you; DeepSeek V4 Flash is a reasonable choice for that exploratory reading, so you can spend the careful attention on the handful of comments that deserve it.
Turn the Thread Into a Tight Summary
Now write. Start with the problem in one sentence, in plain language, and include the version or configuration only when it changes the outcome. Then write what was learned, then what was decided, then what remains open. That order matches the way a reader asks questions: what is wrong, why, what did we do, and what is left?
Keep the summary honest about uncertainty. If the thread ended with a probable cause that was never proven, say so. A confident sentence about a guess is worse than an honest hedge, because the next person will build on it.
- Use concrete nouns from the issue, such as the module name or the failing command, instead of generic words like the system.
- Quote the exact error string once, so it can be searched for later.
- Convert long patches into one line describing what the code changes do.
- State who owns the follow-up work, if the thread makes that clear.
Aim for a summary that stands alone. Someone who never opened the issue should understand the state of the problem after reading it, and someone who lived through the thread should recognise their own reasoning in it.
Check Your Work Against the Original
The last step is verification. Skim your summary beside the thread and check that every claim can be traced to a comment. Delete anything you cannot point to. A summary with one invented detail is harder to trust than a summary that is missing a detail, because readers cannot tell which parts are solid.
Then read the summary aloud, or at least pretend to. If you stumble over a sentence, it is carrying too much. If you have to explain a term, the summary needs a short definition instead of a pointer back to the discussion.
For a polish pass, a stronger model such as Claude Sonnet 5.5 works well when you hand it your draft and ask for contradictions and missing decisions rather than for a rewrite. Keep the wording that already carries the technical facts, and use the model to find gaps.
Summarizing well is a small habit that compounds across a project. Threads get shorter to revisit, handovers get cleaner, and decisions stop disappearing into comment counts. If you want to run these tasks against a range of models without juggling separate accounts, SwiftRelay gives you one OpenAI-compatible endpoint with token-based pay-as-you-go billing that works with Claude Code, Codex, Gemini CLI and any OpenAI-compatible SDK, and you can sign up to receive a small gift credit and try it on the next issue in your queue.