proposal: all: use github discussions for all proposals

[deefdragon]

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.

[seankhliao]

Github discussions have been clearly modeled after Stack Overflow (big top level content, single level of nesting, hides almost all content). That works okayish for Q&A scenarios where there's a single correct answer, but much less well for sprawling discussions.

For our larger discussions, we already see the discussion go around in circles and many comments repeating the same points/questions as posts somewhere in the middle are hidden by default.
There's also been a large increase in the number of low quality, drive by comments.
Moderating this is quite difficult due to many issues with their UI (every action requires a dozen clocks, triggers reloads, and more clicks).

I don't think we should allow more generic discussions to be created.

[earthboundkid]

Discussions work well for packages like slices and maps where the high level is pretty clear and uncontentious, but there are a lot of small details to work out, like the signature of a bunch particular functions or methods. For things like #48287 (how to update APIs for generics), it tends not to work because there are lots of little ideas, but no coherent, well thought through proposals. I am afraid that moving discussions to be all background would tend to make them work less well.

In terms of democratizing discussions, maybe there could be a process where when you propose a new package (e.g. simpleinput 😄) or something else with a lot of small details, if the proposal gets flagged by the committee as worthy of being a good idea but needing fleshing out, then it would flip over to being discussion, which is basically what happened to slices.