r/github • u/Wise_Choice7014 • 2d ago

Showcase Issues vs Discussions: where do you draw the line?

Overlap between GitHub Issues and Discussions gets messy fast unless each has a clear job.

A workable split:

Issues: reproducible bugs, actionable feature requests, and concrete tasks that need tracking to completion.

Discussions: open-ended questions, design proposals, usage help, and ideas that need community input before they're actionable.

Pull requests: proposed changes reviewed against a specific goal.

The tricky part is promotion. A discussion can grow into a feature with clear scope and acceptance criteria, and at that point it needs an issue to track the work.

Issue templates help too, especially for bug reports. But mandatory fields can scare people away from reporting real problems. For a small project, I'd keep templates minimal and write one clear paragraph explaining when to use Discussions.

The maintainer still has to set the workflow, even with both features available.

Question for you: do you keep the Issues/Discussions line strict, or let maintainers decide case by case?

3 Upvotes

64% Upvoted

4 comments sorted by

2

u/[deleted] 2d ago

[removed] — view removed comment

1

u/Wise_Choice7014 2d ago

Low barrier to report. High bar to become an issue

2

u/SheriffRoscoe 2d ago

Discussions are chatter about things that might be implemented someday. Issues are clearly defined problems or features that might be implemented, and which sometimes arise from completed Discussions. Pull Requests are code changes to implement Issues.

No Issue? No PR, period. No chatter in the PR, only comments on the actual code changes (one exception: "Open a backlog Issue about this"). Too much back-and-forth, or too many comments? Reject for rework.