Here's the verdict up front, since most "vs." posts make you scroll for it: use Issues for anything you ever need back — anything with an owner, an outcome, or a deadline. Use Discussions for exactly two things: community Q&A and announcements. That's it.
The uncomfortable truth about Discussions is that for team decision-making, it's a trap. It looks like the right place for open-ended conversation — that's literally the pitch — but a conversation without a resolution mechanism doesn't stay open. It just gets abandoned. Discussions is where conversations go to be forgotten, with a search index over the graveyard.
Now the nuance, because the boundary cases are where teams actually get this wrong.
What Issues are for
Issues track actionable work. A bug report, a feature request, a task. They have a lifecycle: someone opens them, someone works on them, someone closes them. They connect to PRs, they show up on project boards, and they have assignees.
The key property of an issue is that it resolves. It has a definition of done, even if that definition is "we decided not to do this."
Good uses for issues:
- Bug reports with reproduction steps
- Feature requests with a clear scope
- Technical tasks tied to a milestone
- RFCs and proposals that need a decision
Bad uses for issues:
- "How should we think about X?"
- "Has anyone tried Y?"
- General feedback without a specific ask
When you use issues for open-ended conversations, you get issues with 40 comments and no resolution. The issue stays open forever because there's nothing to close — there was never a clear ask.
What Discussions is actually good at
Two things, both involving people outside your team:
Community Q&A. Users and contributors asking questions. Answers get marked, threads stay findable, and your issue tracker stays clean. This is the genuine win — every "how do I configure X?" that lands in Discussions instead of Issues is triage time saved.
Announcements and show-and-tell. Release notes, roadmap updates, "look what I built." Broadcast content where replies are reactions, not decisions.
Notice what both have in common: nothing needs to resolve, nobody owns an outcome, and the audience is the public. The moment either condition changes — an outcome is needed, or the participants are your own team — Discussions starts working against you.
The trap: the "exploratory" team conversation
The case that fools everyone is the RFC-shaped conversation. Someone has an idea and wants feedback before it's a concrete proposal. That feels like a Discussion — exploratory, low pressure, no deadline.
But play it forward. If the idea is bad, the thread peters out and nobody closes anything — fine. If the idea is good, it now needs an owner, a decision, and a link to implementation, and Discussions provides none of those. So someone copies the good parts into an issue, the context stays behind in the discussion, and you now have two half-records of one decision. The better the conversation goes, the worse the format fits.
RFC as Issue isn't great either — the proposal lives in the body, and the feedback mechanism is a comment thread that rots past comment 30. But at least it can close, link to PRs, and appear on a board. Between a format that resolves badly and a format that can't resolve at all, take the one that resolves. Start it as an issue, even when it's exploratory.
What both formats get wrong
Issues and Discussions share the same fundamental limitation: feedback is unstructured.
Whether you're commenting on an issue or replying to a discussion, you're writing freeform text into a chronological stream. Consider what you actually need when you share a technical proposal:
- Specific people to review it (not just whoever wanders by)
- Answers to specific questions (not general impressions)
- A way to see all responses together (not threaded chronologically)
- Input from people who might not have GitHub access (customers, partners, execs)
Issues can't do 2, 3, or 4. Discussions can't do any of them. This matters less for bugs and Q&A. It matters a lot when you need a decision from a group of people.
When you need something else
Use Issues for trackable work. Use Discussions for community Q&A and announcements. But when you need a structured decision from a specific group — an RFC review, a design decision, stakeholder sign-off — the missing layer is structure, and Inkling provides it: write the proposal as a GitHub issue (or paste an existing one), add structured questions inline, and share scoped links with your reviewers — including people without GitHub access. Responses come back organized by question, and a summary gets posted back to the issue thread.
The issue stays the source of truth. You just get better feedback mechanics than a comment thread can provide.