Here is an abridged set of reasons, just because it quickly turns into a very big thing:

1. The barrier to mislabel is too low. There is no confirmation to remove labels. There is no email notification on label change. We've had "accepted" issues accidentally lose their accepted label and enter the quagmire of thousands of unconfirmed issues. Its lost. In this new approach, every issue is critical and you can't do this. You can accidentally _close_ it, but that sends an email notification. This sounds dumb, but it happens, usually due to keyboard shortcuts.

2. The psychological impact of the "open issue count" has real consequences despite being meaningless on its own. People will see a project with 1K+ issues and think "oh this is a buggy hell hole" when 950 of those issues are untriaged, unaccepted, 3rd party issues, etc.

My practical experience with #2 was Terraform ~5 years ago (when I last worked on it, can't speak to the current state). We had something like 1,800 open issues and someone on Twitter decided to farm engagement and dunk on it and use that as an example of how broken it is. It forced me to call for a feature freeze and full on-hands triage. We ultimately discovered there were ~5 crashing bugs, ~50 or so core bugs, ~100 bugs in providers we control, and the rest were 3rd party provider bugs (which we accepted in our issue tracker at the time) or unaccepted/undesigned features or unconfirmed bugs (no reproduction).

With the new approach, these are far enough away that it gets rid of this issue completely.

3. The back-and-forth process of confirming a bug or designing and accepting a feature produces a lot of noise that is difficult to hide within an issue. You can definitely update the original post but then there might be 100 comments below that you have to individually hide or write tooling to hide, because ongoing status update discussions may still be valuable.

This is also particularly relevant in today's era of AI where well written GH issues and curated comments produce excellent context for an agent to plan and execute. But, if you don't like AI you can ignore that and the point is still valid... for people!

By separating out the design + accept into two separate posts, it _forces_ you to rewrite the core post and shifts the discussion from design to progress. I've found it much cleaner and I'm very happy about this.

4. Flat threads don't work well for issue discussion. You even see this in traditional OSS that uses mailing lists (see LKML): they form a tree of responses! Issues are flat. Its annoying. Discussions are threaded! And that is very helpful to chase down separate chains of thought, or reproductions, or possibly unrelated issues or topics.

Once an issue is accepted, the flat threads work _fine_. I'd still prefer a tree, but it's a much smaller issue. :)

-----------

Okay I'm going to stop there. I have more, many more, but I hope this gives you enough for you to empathize a bit that there are some practical issues, and this is something I've both thought of critically for and tried for over a decade.

There's a handful of people in this thread who are throwing around words like "just" or "trivially" or just implying how obvious a simple solution looks without perhaps accepting that I've been triaging and working on GH issues in large open projects full-time non-stop for the last 15 years. I've tried it, I promise!

This is completely a failure of GitHub's product suite and as I noted in another comment I'm not _happy_ I have to do this. I don't think discussions are _good_. They're just the _least bad_ right now, unfortunately.

Yes but the person who is qualified to summarize might not be the person who initiated a discussion.

well that's exactly what they did, limit comments to collaborators. anyone else can comment in the discussion forum.

I'm not saying it does. I'm saying that banning a user who is making a mistake in one area means you lose the value they provide in another (which might be valid issues, but equally it might be 90% of your revenue or something), so it's not always an obvious decision to just wield the ban hammer every time. Moving discussion of issues before they're created to a separate place helps keep the issue tracker focused on issues that are likely to be addressed.

An additional benefit of that is that a user whose discussion leads to a real issue being created will feel like they're genuinely being listened to. That creates a good customer experience, which is good for your brand's reputation. It's a positive experience. Closing non-issues in the tracker is a negative experience.

> Why break the expected/established workflow of users

Is it really that hard to open a discussion?

each project has its own workflow. no established workflow is broken. github traditionally imposed a different workflow because initially it didn't even have discussions.