Since their introduction in 2021 to the golang project, there have been nearly 2 dozen discussions. These have garnered a lot of good feedback around many different topics, and have resulted in several large changes to the language and standard library (slog, slices and maps libraries to name a few). Their current usage however, is not perfect, and leaves them in a bit of an odd state with regards to the rest of the proposal process.

I see three issues with discussions as they are currently.

1. Discussions feel created somewhat at random
2. Discussions often end up railroaded around the discussion creators suggestion and have decreased brainstorming of other solutions
3. Discussions sometimes get left with no closure.

Creating Discussions

What discussions get created, and when, appears effectively up to the whims of those who have the permissions to create said discussions. I'm sure there is atleast some informal process, and that if one of these individuals was emailed with a good enough discussion topic, a discussion might get created, but that is rather opaque.

My suggestion here is to create a documented method that any individual can submit suggestions for discussions to be created. I can see three potential options, but each has flaws.

1. Create a dedicated email address that that discussion requests can be submitted to and reviewed,
2. Have a "Meta" discussion that discussion ideas can be submitted to and discussed as to if they would be better discussions or proposals
3. Add an issue type for requesting discussions/create discussions from proposals.

Railroading

When creating the first discussion (#47139) as an announcement of their usage, @rsc said (emphasis mine)

We are trying out GitHub Discussions as an alternate place to have these kinds of structured discussions, especially for feedback on pre-proposal ideas.

I feel this is not using them to their full value and often leads to the discussion railroading quite quickly. The discussions in the past have almost always been started with the creator of the discussion suggesting a solution to the problem. Almost all of the following comments and threads are then around the creators solution, and there is very little suggesting of potential alternatives and different perspectives in comparison.

I would suggest that discussions should be put forward closer to the form of a question instead of a solution. An example of this might be "How should go approach iterators?" for #54245. That discussion started with Background, Proposal, Appendix: Iterators in other languages and a few other sections. Under new form, the Background, and Appendix: Iterators in other languages sections could be included almost unchanged when the discussion is first created. (tho adjusted slightly to not make assumptions about a potential solution)

The Proposal, Examples and Future extensions sections could be added after the community has had some time to discuss the problems and suggest their own potential forms and solutions. Two weeks or so feels appropriate for a wait time. Enough time for people to see the discussion in the minutes and read and comment.

A discussion railroading around one solution eventually is fine (if not desirable for the purposes of creating a proposal). The goal here is to provide a cleaner canvas of initial discussion instead of one that is biased towards one particular solution.

Closure

This has somewhat been remedied recently with the closing & locking of most of the discussions that were previously open, however many of these discussions have gotten no notice as to if they are going to get proposals created, or not created. This leaves certain potential new language features as "potential" and blocks existing features from being added. Very specifically, some functions were not added to the maps/structs libraries because of the iterators discussions. At this point, there has been no proposal created for adding iterators, but the discussions are both closed. This leaves attempting to add those functions to the libraries in a sort of limbo.

My suggestion here is that discussions should have a life-cycle similar to that of the proposals. Once the comments have slowed down or reached a given consensus, the discussion should have a last call for comments, and then be closed. Importantly however, when closed, the discussion should be updated to denote if a proposal is being created or not (ideally linking to said proposal if one exists). Proposals created from discussions should be created quite quickly after the discussion's closing to prevent just moving where discussions get stuck in limbo. This closing would allow things that are waiting on the given discussion to move on.

I believe given the limited number of discussions that have been created, it would also be beneficial for the closed discussions to be retroactively updated to reflect if a proposal was/is planning on being created or not.