What converting an issue to a discussion actually does
Someone opens an issue on your repository with a loose idea.
There is no bug to fix and no clear task to complete, but the conversation could be valuable.
GitHub lets you convert an issue into a discussion with a few clicks.
The platform documents this as a moderation tool for ideas still in early development.
The short answer: convert when the thread is an open conversation with no closable outcome, and keep it as an issue when it describes work that can be finished.
The rest of this guide shows how to make that call with confidence.
According to GitHub's moderation documentation, when you convert an issue to a discussion, the discussion is automatically created using the content from the issue.
You pick a category during the conversion, confirm the action, and the conversation moves out of your issue tracker.
The mechanics are simple.
Open the issue, find the Convert to discussion option in the right margin, choose a category from the dropdown, and confirm.
People with triage access to a repository can moderate its discussions, which includes converting issues this way.
What you gain is a different kind of space.
GitHub describes Discussions as an open forum for conversation among maintainers and the community.
Issues, by contrast, are built around work that can be closed: a bug fixed, a feature shipped, a question resolved.
Converting moves the thread from a task list into a forum.
When conversion is the right call
The clearest signal is that the item has no finish line.
If you cannot picture writing closed as completed on the thread, it probably belongs in a discussion.
GitHub's own guidance frames conversion as the tool for ideas still in early development, before they have hardened into a concrete proposal.
Use these checks when triaging:
- No actionable outcome. The thread is brainstorming, feedback gathering, or an open question for the community rather than a defined task.
- Multiple valid directions. The conversation is exploring options, not converging on one fix that a pull request could deliver.
- Community input is the point. You want broad participation, not a maintainer decision recorded in a tracker.
- The issue is clogging triage. An idea sitting open for a long time with no owner distracts from real work items.
A concrete pattern: a user opens an issue titled with a feature idea and writes several paragraphs of what if thinking.
There is no spec, no agreement it should exist, and no way to test it.
Converting it to a discussion in an Ideas category keeps the thinking alive without letting it masquerade as committed work.
When you should keep it as an issue
Conversion is not a tidy-up tool for anything inconvenient.
Some things lose real value when they leave the tracker.
- Reproducible bugs. A bug report has a lifecycle: reproduce, fix, verify, close. That lifecycle lives in issues.
- Concrete feature requests with clear scope. If the request describes a specific change you could accept a pull request for, it is work, not conversation.
- Items tied to labels, milestones or assignees. Conversion moves the content, but your planning workflow around the issue does not follow it into a forum.
- Anything you use for roadmap prioritization. If your team sorts issues to decide what to build next, converting an item removes it from that queue.
There is also a social cost to over-converting.
If contributors notice that their reports regularly get moved to a discussion nobody reads, they learn that opening an issue is pointless.
Use conversion to route conversations honestly, not to make the issue list look smaller.
Pick the right category before you convert
Every discussion must live in a category, and each category has a format: open-ended discussion, question and answer, or announcement.
Repository administrators and people with write or greater access define these categories.
GitHub's default set includes Announcements, General, Ideas, Polls, Q&A and Show and tell, and each repository or organization can have up to 25 categories.
The format matters more than the emoji.
A Q&A category lets maintainers mark a comment as the answer, and GitHub highlights that comment and its replies so visitors can find the resolution quickly.
An open-ended category suits the Ideas and Show and tell patterns where there is no single right reply.
Announcement categories are the opposite of what you want here: only people with maintain or admin permissions can start discussions in them, though anyone can comment.
Before converting, check that a fitting category exists.
If your repository only has the defaults and none of them match, either pick the closest open-ended fit or create a category first.
A discussion dumped into General with no description is only marginally better organized than the issue it came from.
A worked triage example
Here is an illustrative scenario, not a record of a real repository.
A community builder maintains a small open-source tool.
Several items arrive within a short period: a crash report with repro steps, a request for a specific export format, and a long post about supporting a new platform.
The crash report stays an issue.
It has a defect, a reproduction path and a closable outcome.
The export format request also stays an issue, because it names a concrete change someone could implement.
The platform speculation becomes a discussion in an Ideas category.
The author keeps their content, and other users can weigh in without appearing in the issue tracker.
If the conversation converges on a real proposal, a new issue can reference the discussion.
The decision in each case came from one question: does this thread describe work, or does it host a conversation?
What happens to the conversation after conversion
Converting is a one-way move in practice.
The issue becomes a discussion created from its content, and your issue tracker no longer shows it.
Plan for that before you click.
- Link back if needed. If other issues or documentation reference the converted item, add a comment or note pointing to the new discussion location so followers are not stranded.
- Set expectations in the discussion. A short opening comment explaining why the thread moved and what kind of input you want keeps the conversation productive.
- Remember moderation tools carry over. In a discussion you can lock unconstructive threads, and in Q&A categories you can mark answers, so a converted idea can still be kept healthy.
Discussions can be transferred between repositories, with the documented exception of announcements.
So a category choice is not permanent if your project structure changes later.
How this fits into a wider triage habit
Conversion works best as one move in a consistent triage routine rather than a rescue act for a neglected backlog.
If you regularly review new issues, decide work-versus-conversation early, and route accordingly, both your tracker and your forum stay useful.
Some maintainers experiment with automation for that first sorting pass.
If that interests you, read about the tradeoffs of using AI to triage GitHub issues before wiring anything up.
Your repository setup shapes the options too.
If you are weighing a public or private repository, consider that discussions only build community value where people can find and join them.
If your project spans multiple repos, moving repositories into an organization can centralize discussions at the organization level.
That changes where your categories live.
The short answer
Convert an issue to a discussion when the thread is an early-stage idea or open conversation with no closable outcome, and a suitable category exists.
Keep it as an issue when it describes a bug or a concrete, scoped change.
When in doubt, ask what closing the item would look like: if there is no answer, it is a conversation, and conversations belong in Discussions.
One question settles most triage calls: can this thread ever be closed as done? If not, it is a conversation, and GitHub Discussions is where conversations live.
For the documented behavior behind this guide, see GitHub's pages on moderating discussions and managing categories for discussions.
Take the next step with Ideoreto. Use the ideas in this guide as a starting point for your next project.
Register for Ideoreto to get started.