GitHub Discussions is modelled poorly for open-ended conversations

Note that this article criticizes GitHub’s Discussions feature (originally launched in 2017) as it exists now, in July 2025.

In case you don’t know, Discussions is GitHub’s answer to forums and Stack Overflow-style Q&As. Users can reply to an initial message in a discussion and upvote, downvote, or comment on any response. In addition to announcement threads and polls, discussions can either be open-ended discussions or question/answer discussions.

Question/answer discussions:

• can be viewed in one of a few sort orders (top voted first; newest first; oldest first) and
• can have a single response marked as “the answer” to the discussion.

Open-ended discussions:

• can also be viewed in one of a few sort orders (top voted first; newest first; oldest first) and
• do not have any response marked as “the answer.”

The Q&A discussions improve upon the Stack Overflow model in an important way: the project itself is the owner of the discussion board. That means that project administrators are hypothetically present, moderating conversations and correcting potential mis/disinformation.

User interface deficiencies

Unfortunately, unlike the Q&A discussions, the open-ended discussions feature is an afterthought in comparison. Even visually, responses to open-ended discussions look disconnected from one another. Each response is an island, with borders, primed for its own disparate comments thread.

While Discourse threads and GitHub issues both have their own user interface challenges and deficiencies, issues are displayed more like I would personally expect open-ended discussions to be displayed: a single conversation, without nested comments, and visually each message in the issue is linked to indicate a chronology. Interestingly, issues can be converted into discussions by project administrators–but not the other way around (for reasonable complexity-related reasons, I’m sure), though admins can create an issue from a discussion.

As a GitHub repository administrator, you must configure Discussions and the project’s enabled discussion categories. Each category will allow for discussions of one type (announcements; polls; Q&As; open-ended discussions). When creating a new discussion category, the default selected mode is question/answer. In my experience, this really shows. For example, see Laravel’s “Show and Tell” discussion category, which contains hundreds of “unanswered” links and plugs that members of the Laravel community may find relevant. No offence to anyone (I’m not a member of the Laravel community), but calling these “unanswered” feels like a mistake. Given this example, and the visual design of the discussion page, it seems clear that GitHub’s designers prioritized the functionality of the Q&A-style discussions.

All four discussion types have the exact same threading system, well-suited to Stack Overflow-like Q&As, and less well-suited for announcements made by project maintainers and open-ended discussions. For all four discussion types, responses can be upvoted individually and have their own nested comments threads. This specifically makes having an open-ended discussion quite complex: open-ended discussions are now not just open-ended, but also achronological, non-linear, or single-threaded, depending on how nested comments are (ab)used.

De-linearizing conversations

Years ago, I started a discussion on the Solidus project to have an open-ended discussion about how to handle a particular issue I was facing integrating with the Solidus framework’s provided frontend templates. There was no need for upvotes (or downvotes, thankfully), but all responders ended up commenting on a single response to the thread. The shape of this discussion would have been better suited to a single, flat thread, i.e.:

# original post -> [responses]

Original Poster   "Hi, this is a question or comment about The Project."
Responder 1       └── "Hi, this is a response to the question or comment."
Responder 2       └── "Hi, this is also a response to the question or comment, but I'm also in conversation with Responder 1, who responded before me."

rather than the tree structure it ended up as due to the GitHub Discussion’s design choices:

# original post -> [response -> [comments]]

Original Poster   "Hi, this is a question or comment about The Project."
Responder 1       └── "Hi, this is a response to the question or comment."
Responder 2           └── "Hi, this is also a response to the question or comment, but I'm also in conversation with Responder 1, who responded before me."

The tree structure makes the otherwise-linear conversation full of potential for non-linearity and complexity. After all, this is purportedly a single discussion. Imagine what this simple, linear conversation would look like with ten, or fifty, more participants.

Perhaps my discussion should have actually been a GitHub issue to begin with. Or, maybe, a message from the discussion should have been used as the source for a new issue. Well, it doesn’t matter. This discussion has long been abandoned and no action has been directly taken as the result of it. It’s meaningful that issues imply actionability and discussions do not, but I find it troubling that issues prioritize the chronology and linearity of a conversation while GitHub’s open-ended discussions don’t.

GitHub’s announcement blog post for Discussions describes the feature as “dedicated space for conversations,” and now, years later, that still feels untrue as I attempt to use these features or read past discussions. It also describes the feature as a way to “create a home for your community,” despite most discussion boards I’ve seen more closely resembling a community support, Stack Overflow-like Q&A feed.

“Just using it wrong”

There is a place for nested conversations. I don’t think the GitHub discussion I started is one of them. The nested response-comments makes the conversation look like the first responder’s comment is more important than the following comments. The structure and styles of the HTML document tell that story, too. Any discussion-readers not participating or reading closely might not understand that all of these messages are in response to the original discussion message equally.

You could minimize this by saying discussion participants are not using Discussions “properly.” Hm, but should a responder have to think that hard about whether to respond or comment on a response? Should they have to make this worse by accepting a previous commenter or responder’s decision to “use the feature wrong”? In the world of Stack Overflow-like Q&As, this complexity makes sense. For an “open-ended discussion” it does not.

GitHub’s own documentation about how to participate in a discussion is quite complex:

• Comment in response to the original comment from the author of the discussion
• Create a comment thread by replying to an individual comment that another community member made within the discussion
  …
• Upvote discussions and top-level comments to give them more visibility

As a way to describe the critical functionality of a message board, these participation instructions seem complex. Unfortunately, you can’t just say “reply to a thread,” or “contribute a message to the conversation,” because these things aren’t really conversations.

I don’t have much more to say about this other than I don’t think Discussions is a good form factor for most real, meaningful discussions, and they definitely aren’t good at being the primary forum for conversations being had by serious free and/or open-source software projects.