Can You Convert a GitHub Discussion Back Into an Issue Without Losing the Thread?
No, not as a real conversion. GitHub ships exactly one direction as an actual convert action. An issue's sidebar has a "Convert to discussion" option, documented in GitHub's discussion-moderation guide, and using it turns the issue's content into a new discussion. There is no dedicated docs article for the reverse, and none of the current Discussions documentation lists a "convert to issue" action anywhere in its table of contents.
What you get instead, and what maintainers have used since it shipped, is a way to open a brand new issue that references the discussion. It is not a conversion. The discussion stays exactly where it was, unlocked and unclosed, with all of its replies still living there, and the new issue starts with an empty comment thread of its own. If a feature request picked up eight replies in a Discussions "Ideas" category before someone decided it was worth building, none of those eight replies travel to the issue automatically. You either copy the useful parts by hand or the person who argued for the feature never sees their own case attached to the thing that tracks the work.
Why the two directions aren't mirror images
Issue to discussion exists because GitHub built it for a specific moderation job. It turns an open-ended bug report or question into a conversation once a maintainer decides it isn't actionable work. It's a real, first-class action, and it has had real bugs. A February 2025 community thread describes the convert button redirecting to a 404 while leaving the original issue open and, in some cases, locked, until GitHub's team shipped a fix that March. That thread is worth reading for one reason beyond the bug itself. Even the direction GitHub officially supports hasn't always worked cleanly, a useful data point before assuming the unsupported direction will behave predictably.
Discussion to issue has no equivalent first-class action because the two objects serve different purposes. A discussion is built for back-and-forth with no single resolution, categories like Q&A, Ideas, and Announcements. An issue is built to be closed. Wanting to promote a discussion into an issue is really wanting to change what kind of object it is, and GitHub has never treated that as symmetric with collapsing an issue into a conversation. A long-running request thread asking for exactly this, opened in 2021, eventually got a reply pointing to a "create issue from discussion" option in the discussion's menu, and a separate thread spells out what that option does. It opens a new, separate issue pre-filled with a link back to the discussion. The discussion isn't deleted, replaced, or merged. It just now has a linked issue sitting next to it.
The pattern that keeps the thread attached
Given that the platform won't do the merging for you, the manual version has three steps that matter, in order:
- Open the new issue with the discussion's content quoted in, not just linked. A bare "see discussion #412" forces every future reader to click through and reconstruct the ask. Paste the original post and the two or three replies that shaped the decision, with attribution ("as @user described in the discussion...").
- Comment on the discussion with the issue number, and say plainly what happens next, something like "Filed as #418 to track the actual build, following up here if the approach changes." The person who started the thread should not have to guess where their request went.
- Decide the discussion's fate on purpose. Locking it with a comment pointing at the issue is fine if the conversation has run its course. Leaving it open invites new replies that never reach the issue. Either is defensible; leaving it ambiguous is what produces the "wait, so what happened to my post" messages later.
Step three is where the confusion the primary question is worried about originates. A reporter who watches their discussion get quietly locked, with no comment explaining that the real work moved to a linked issue, reads that as their idea getting closed and dismissed. The fix costs one sentence.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionA worked example: Driftloom's queue-priority thread
Picture a small maintainer team running the three-step pattern above. Emil Halvorsen maintains Driftloom out of Pinepoint Labs, a two-person shop. Driftloom is a fictional stand-in, an open source job-queue library invented for this walkthrough. Someone opened a Discussions "Ideas" post titled "Per-queue priority weighting?" describing a workaround they'd built with two separate queue instances, and asking if it was worth supporting natively.
Six replies came in over three weeks, two from teams describing similar workarounds and one from a contributor sketching a rough API shape in a follow-up reply.
Contributor (@marlo-dev): "Could work as a
priorityoption onenqueue()that maps to an internal weighted round-robin. I'd be up for a first pass if the maintainers are onboard."
Emil decided it was real scope, not a discussion topic. He opened issue #203, titled "Add per-queue priority weighting to enqueue()," and pasted the original post plus marlo-dev's API sketch directly into the description, crediting both by GitHub handle. He commented on the discussion, "Filed as #203, the priority-option shape from this thread is the starting point, following up there." He left the discussion open rather than locking it, since two other people were still comparing workarounds in it.
Three weeks later, when the feature shipped in a minor release, Emil went back to the discussion to post the changelog link. The two teams who'd described workarounds both replied there, thanking him, in the same thread where they'd first asked. Nothing about the original ask needed reconstructing, because the issue had carried it from the start.
Where the manual habit stops holding up
This works fine for one maintainer moving a handful of discussions a month. It runs into the same three problems every manual cross-referencing habit does, once a project grows past that:
- The quoting step gets skipped under time pressure. A one-line "see discussion #x" is faster to type than pasting three replies with attribution, and busy maintainers take the faster path.
- Multiple maintainers do the pattern differently. One locks discussions immediately, another leaves them all open indefinitely, and a new contributor can't tell which convention applies without asking.
- The requester's identity lives in prose, not a field. "As @user described" is a sentence, not something you can filter by later. Six months on, nobody can pull "everyone who asked for priority weighting" without rereading two threads.
That last one is the same gap covered in how to triage GitHub issues at scale. A tracker that only records what was said, not a queryable link to who said it, degrades as volume grows regardless of how good the initial habit was.
Where Modem fits
Modem doesn't watch Discussions today. Its GitHub integration syncs issue and PR metadata from your connected repos, captures issues as feedback, and matches merged PRs back to the people who asked for the underlying change. A discussion sits outside that sync until its content lands somewhere Modem does watch, and that's a real limitation worth naming plainly rather than the reason to run the three-step pattern above. The reason to run it is the one that mattered before Modem entered the picture. Get the request in front of whoever can build it, and tell the person who asked where it went. Once Driftloom's #203 exists as an issue, Modem attaches it to a topic alongside anything else that mentions per-queue priority, whether that shows up in a Slack DM, a support email, or another issue. The topic doesn't lock onto one bucket, and a thread stays linked to whoever raised it no matter which of those it started as, which is the payoff once cross-referencing by hand stops scaling for one person. This framing comes from a company that sells the downstream sync, so read the fit judgment with that bias in mind, not as neutral advice.
If your project runs on a handful of maintainers doing the three-step pattern above consistently, that's a genuinely sufficient system. The same "don't lose the thread on the way to the tracker" problem shows up in other tools too, including the Jira Service Management version of this question, if GitHub isn't the only place your team runs into it.
The next one you promote
The next time a discussion is clearly heading toward becoming real work, open the issue, paste the two or three replies that mattered with attribution, comment the issue number back on the discussion, and say out loud whether you're leaving it open or locking it. That's the whole habit. It takes about the same two minutes as the process feels like it should take, and it's the two minutes that keep the person who asked from wondering what happened to their post.
