What GitHub Issues are built for
When you have an early idea, the place you write it down shapes what happens next.
GitHub gives you two main options: Discussions and Issues.
They look similar, but they serve different stages of an idea's life.
Choosing the right one keeps your thinking open when it should be open and turns it into trackable work when it is ready.
This guide explains what each tool is for, how to decide where a new idea belongs, and how to move an idea from one to the other without losing the conversation that shaped it.
Issues are GitHub's tool for planning, discussing, and tracking work.
According to GitHub's documentation, you can use issues to track ideas, feedback, tasks, or bugs, and they are quick to create and flexible in how you use them (About issues).
In practice, an issue usually represents something concrete: a bug report, a planned feature, or a task someone will pick up.
Issues come with structure that helps you manage work.
You can add labels, milestones, and assignees.
You can break large pieces of work into sub-issues and define blocking relationships between them.
You can also connect issues to pull requests, so that merging a change can automatically close the related issue (About issues).
That structure is a strength when an idea has become a commitment.
It is a burden when the idea is still raw, because an issue implies someone should eventually act on it.
What GitHub Discussions are built for
Discussions are a collaborative communication forum for the community around a project.
GitHub describes discussions as transparent, accessible conversations that need not be tracked on a project or relate to code (Quickstart for GitHub Discussions).
Discussions are organized into categories you define, such as ideas, questions, or announcements.
In question-and-answer categories, you can mark a comment as the answer.