GitHub Discussions vs Issues for feature requests

GitHub Issues track work; GitHub Discussions hold conversation. A feature request that nobody has agreed to build yet belongs in a Discussion, and it moves to an Issue once someone intends to act on it. Everything below about GitHub itself comes from GitHub's documentation, read on 2026-09-24.

What is the difference between GitHub Discussions and Issues?

GitHub Issues are for planning, discussing and tracking work in one repository, and GitHub Discussions are a forum for conversations that are not about code. GitHub's docs describe Issues as "often referred to as GitHub's bug-tracking system", specific to a repository and usually with a clear owner. They describe Discussions as "like a forum" and note that they "often do not result in an actionable task".

Every Discussion lives in a category. GitHub's default categories are six: Announcements, Ideas, Polls, Q&A, General, and Show and tell. Only people with maintain or admin permission can start a Discussion in an announcement category, and in a question-and-answer category the Discussion's author, or anyone with triage permission or higher, can mark a comment as the answer.

When should a request be a Discussion, and when an Issue?

Make it a Discussion when it is still a question or an idea, and an Issue when it is work someone will do. GitHub's own Ideas category is described as "Ideas to change or improve the project", and anyone can sort Discussions to see which have been upvoted the most, so the requests people want most rise to the top.

GitHub does not draw the line as tightly as that. Its docs list "I want to share feedback about a specific feature" as a reason to open an Issue. A reasonable rule for a maintainer:

• A bug with steps to reproduce: an Issue.
• A concrete change you have agreed to make: an Issue, so it has an owner.
• A request that needs debate, or a vote, before anyone agrees: a Discussion in Ideas or your own feature-request category.
• A how-do-I question: a Discussion in a question-and-answer category, so the right reply can be marked as the answer.

How do you turn on GitHub Discussions for a repository?

A repository owner, or anyone with write access, turns Discussions on from the repository's settings. It works on public and private repositories, and the Discussions inherit the repository's visibility.

1. On the repository, under its name, click Settings.
2. Scroll to the Features section and click Set up discussions. (GitHub's settings page words the same step as selecting Discussions under Features.)
3. Edit the welcome template GitHub drafts for you.
4. Click Start discussion.

To switch Discussions off again, deselect Discussions under Features. For an organization, Discussions use one repository in the organization as the source repository.

Can you convert a GitHub Discussion into an Issue, or an Issue into a Discussion?

An Issue converts into a Discussion; a Discussion only seeds a new Issue. The two directions behave differently.

1. Issue to Discussion. On the Issue, in the right margin, click Convert to discussion. GitHub creates the Discussion from the Issue's content.
2. Discussion to Issue. Anyone with triage permission can create an Issue from a Discussion. The Discussion's post is copied into the new Issue's body, and GitHub states that this "does not convert the discussion to an issue or delete the existing discussion".

Gitback probed GitHub's API for this, and the findings are in its product map. GitHub's GraphQL schema lists 260 mutations and none of them turns an Issue into a Discussion. The conversion exists only in GitHub's web interface. What the API does expose is a read-only timeline event, ConvertedToDiscussionEvent, which says a conversion happened. A conversion made in the web interface keeps the original author, the original creation date and the comments under their own authors; there is no way to undo it, and the Issue stays closed and locked.

That changes what a tool can honestly offer. A "convert" button in a third-party app would have to recreate the Issue as a new Discussion under the app's own account, dated now, with the reactions lost. Gitback does not do that.

How do you keep feature requests from cluttering Issues?

Give requests a home in Discussions and move the stray ones there. Two steps in GitHub alone:

1. Turn on Discussions, as above, and use the Ideas category or add one of your own for feature requests.
2. When a request arrives as an Issue anyway, use Convert to discussion. GitHub's docs describe this exact use: "Convert open-ended issues into discussions."

When a Discussion earns a place on the plan, create an Issue from it and keep the Discussion open as the place people keep voting and talking.

Where does Gitback fit, and what does it not do?

Gitback builds one public Board for a GitHub repository from that repository's own Discussions, Issues and Releases, and keeps no copy of them. Two of the Board's five Modules map straight onto this guide.

Discussions become the Feedback Module. The Module reads one Discussion category, chosen by a per-Board Category Mapping because category names differ from repository to repository. When nobody has chosen one, Gitback picks a default. It prefers a category that does not take answers, and ranks Announcements below the other such categories because only maintainers can post there; question-and-answer categories come last. Within a rank, a category with recent discussions beats a quiet one, then the names Feedback, Ideas, Feature requests and General win in that order. An End User posting through the Board picks Bug report, Feature request or Feedback. Labelling a Discussion needs write permission an End User does not have, so Gitback stores the choice as an HTML comment at the end of the post, invisible on github.com. A Vote on the Board is a 👍 reaction by a real GitHub account, not GitHub's own Discussion upvote.

Open Issues become the Roadmap Module. It reads the repository's open Issues and places each in one of four lanes: Open, Planned, In progress and Complete. Three of those lanes are labels on the Issue, roadmap: planned, roadmap: in progress and roadmap: complete, and Open is an open Issue with none of them. In the Issues Module, a Client who has given footprint consent can press Import to roadmap, which adds the roadmap: planned label and moves the Issue to Planned.

The Issues Module also carries the conversion. Next to an Issue, a Client sees Move to Discussions on GitHub, which opens the Issue on github.com with the instruction to use GitHub's own Convert to discussion. After converting, the Client presses I moved this — re-check, and Gitback reads the Issue's timeline once to find the new Discussion, following it even into another repository or an organization.

What Gitback does not do:

• It does not turn Discussions on. It reads whether they are on. When they are off, the Feedback Module says so, "GitHub Discussions are switched off for this repo, so there is nowhere to post feedback yet", has no composer, and links to the repository's open Issues instead.
• It does not create Discussion categories. GitHub's API cannot create them at any permission level, so a repository with Discussions but no categories at all needs one added on GitHub first.
• It does not convert Issues to Discussions, for the reasons above.

To try it on your own repository, follow Open a Gitback Board for your repo and claim it, or paste the repository's URL at Open a Board. Private Boards are on the pricing page, and more guides like this one are in Guides.