I respectfully disagree. I feel the process you propose would be too heavy weight. I think it's perfectly fine to propose a feature without having to design all details of it. Especially because it always needs to be discussed whether or not many people are interested in the feature or not.

The current proposal process is fine, but the document at https://github.com/golang/proposal/blob/master/README.md is outdated, because it still mentions that language changes are unlikely to be accepted. Rather, there are new criteria for this in: https://blog.golang.org/go2-here-we-come which should be integrated into the former document.

Secondly, the latter blog post mentions that there will be a Go2 task force. It would be nice to hear who they are and to see that they are getting active. One document which they could produce is a list of language features that were rejected and thus not likely to be added plus rationale, and a list of features that are under discussion and that may become part go Go in the future, with the status of these issues and the problems that are still blocking the feature.

Anybody can see Go 2 language proposals that were rejected at https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+label%3Ago2+label%3Alanguagechange+ . (There are currently 168 such proposals). Each issue has a comment or discussion about why it was rejected.

Thanks for the suggestion, but I don't really see how this would make things better. While the current language proposal process is hardly perfect, I don't think the problems are due to a lack of formal processes.

Go is a language that has always developed based on practical use. Ideally language change proposals should flow from people who know the language well and are actively using it. Where they find areas where they are unable to express important concepts, or find them awkward to express, they can look for ways to improve their experience. So having the core Go team issue "feature requests for proposals" doesn't feel right. Those should ideally flow organically from people using the language.

Or to put it another way, if we did issue feature requests for proposals, I think we would simply point out the same areas where many people are proposing changes anyhow, such as some form of readonly or immutable values, or error handling (for which there is already a design draft). We would point out those areas because many experienced Go programmers encounter problems in those areas and some of them are moved to make language change proposals. There are no esoteric areas where Go needs improvement, or, rather, I'm sure there are, but we wouldn't ask for improvements in those areas anyhow because they don't really come up in practice.

@ianlancetaylor , thanks for the tip. I guess I can use a similar https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ago2+label%3Alanguagechange+ to see the open issues . Also, rereading the document I realize that you, in essence, are the "Go 2 task force", right? From the list of closed issues I can see you have been very active in this lately, so I'd like to thank you for your efforts. So I apologize if I came off impatiently in my previous message.

However, I still think that the README.md should be updated to reference the blog post for clarity.

I'm not really the "Go 2 task force." I don't think we really have a "task force," although that sounds energetic; I would say that we have a "committee." I'm just the person who takes notes for the committee. Actually, it's more like I take notes for the preliminary committee which filters out the issues that are obvious non-starters and classifies other issues for a deeper look by more people. The preliminary committee is me, @griesemer and @bradfitz.

You didn't seem impatient, no need for an apology.

I agree about the README, I'll do something now.

Change https://golang.org/cl/158843 mentions this issue: README: mention current Go 2 process

@ianlancetaylor

if we did issue feature requests for proposals, I think we would simply point out the same areas where many people are proposing changes anyhow

The value of Feature RFPs is not merely to "point out" a problem, it's to describe and publicize requirements for an acceptable solution, and thereby solicit comprehensive, workable Feature RFCs.

IMHO, the FRFP approach would be more effective for the Error Handling issue than the tack taken to date. The Draft Design for Error Handling contains essentially zero functional requirements, and no mention of possible extensions to its novel concept. You're probably familiar with my menu of possible requirements for Go 2 error handling; that is what an FRFP would contain. (I'm not familiar enough with the Draft Design for Generics to comment on it.)

Also, inviting the community to submit FRFC documents to fix a widely-discussed problem is a community building exercise. If the process resulted in the adoption of a concept originating outside the Google team, it would demonstrate that in the Go open source community, the best ideas win.

@beoran

the process you propose would be too heavy weight

As I wrote in the text, "An FRFC that addresses an FRFP could be fairly short; the first draft might be a collection of commented code samples."

Asking the author of a standalone FRFC to describe the requirements driving their design is a blessing, not a burden; understanding & documenting requirements both clarifies the design concept and yields a more productive discussion.

The current proposal process encourages people to throw barely-cooked spaghetti at a wall; not a good use of anyone's time. It would be more illuminating to see simple bug reports like, "Clients misuse this third-party API due to lack of immutable/read-only arguments," which detail a specific problem.

@ianlancetaylor Thanks for your efforts, and those of everyone on the "commitee". Though I suggest you rename yourselves the "Go 2 Preparation Task Force", because, as you say, that sounds more energetic. :) Good to see the README will be updated.

@networkimprov I don't see any problem with people just throwing an "barely-cooked spagetti" idea "at the wall", or, more likely, here in the issue tracker, because that encourages everyone to participate. It also makes it clear which new language features many people are interested in, as per Go2 ciriterium 1. That is the first step, identify a need for the feature.

Of course, once an issue turns out to be in high demand, then there will be a long discussion to work out the details. For that, I agree that it might be a good idea to have everyone who wants to flesh out the proposal to write a Go Language Feature Design Document, in stead of just making a few comments here and hoping someone else will do the hard work of actually designing the feature.
Probably current design documents like this: https://go.googlesource.com/proposal/+/master/design/19308-number-literals.md could serve as a template. As you suggest, an extra "requirements" chapter could be added between "background" and "language change".

The current counter proposals, for, say, the error handling feature are often quick blog posts or short comments so they can't easily be compared with each other. Having a common GLFDD would help with that considerably, and also help to weed down the possible implementations for a feature.

I'm having a hard time distinguishing this suggestion from the current proposal process.

It sounds like what you are describing is basically step 3 at https://go.googlesource.com/proposal#the-proposal-process, namely writing a design doc.
(See also https://go.googlesource.com/proposal#design-documents.)

One reason we don't jump right to step 3 is precisely to reduce work for authors in the common cases where (1) the proposal is definitely fine without a worked doc or (2) the proposal is definitely not going to be accepted, or has been discussed before, or has some fatal flaw in its current form that would be easier to adjust in a brief discussion before writing a long doc. That seems like a real benefit.

What, concretely, would you change about the current proposal process, and how would you make sure not to give up the benefit mentioned in the previous paragraph?

Meanwhile, there has been relatively little published response to the feedback and counter-proposals regarding the Go 2 Draft Designs for Error Handling and Generic Programming.

For what it's worth, we called those draft designs precisely because they are not yet firm enough to be considered real proposals. They're sketches of what we're thinking, to provoke discussion, not to provoke a formal process. They also happen to be elaborate because they tend to touch a lot of issues, but we don't expect that to be true of all proposals, or even most. You can get a sense of the variety of proposal complexity by skimming through the "Proposal-Accepted" label on this issue tracker.

I am not at all suggesting that new feature proposals should begin with a Design Document.

Above I called for
a) "guidance by the Go team regarding which sorts of features have priority ..." and
b) "detailed guidance about priority features [to] leverage the whole community for development of comprehensive proposals".

I then suggested the "Language Feature Request for Proposal (FRFP)", which is issued by the Go team, and answered by any number of "Language Feature Requests for Comment (FRFC)", which anyone may submit.

An FRFP a) describes a problem of current practice, b) summarizes relevant experience reports, and c) identifies functional requirements. It's similar to a Design Document, but it does not propose a design. Only the Go team publishes FRFPs.

An FRFC offers a design, giving a) semantics & syntax, and b) use cases. An FRFC first draft could be brief, e.g. "a collection of commented code samples". If it leaves unaddressed any requirements in the relevant FRFP, it should explain why. It does not describe a problem (unless it's a standalone FRFC, see below). Anyone may publish FRFCs.

The numerous counter-proposals sparked by the Go 2 Draft Designs demonstrate that many in the Go community immediately interpreted the Draft Designs as FRFPs.

In my response to @ianlancetaylor I wrote, "the FRFP approach would be more effective for the [Go 2] Error Handling issue than the tack taken to date. The Draft Design for Error Handling contains essentially zero functional requirements, and no mention of possible extensions to its novel concept. You're probably familiar with my menu of possible requirements for Go 2 error handling; that is what the FRFP would contain." The proposed syntax & semantics would appear in a separate FRFC.

There is also a need for a standalone FRFC (that doesn't address any FRFP), which would include "an outline of potential requirements for any reasonable solution". Its first draft could be brief; a code sample following each requirement listed. This is similar to a Design Document, but can begin as a short email.

The process I suggest would "not apply to minor language adjustments ... or stdlib proposals, which are by definition more modest in scope and impact than new language features."

P.S. I tried hard to make all this clear in the issue text and my one follow-up comment. Any input on improving the text would be welcome.

This proposal adds a layer of bureaucracy on top of the existing proposal system. While the goal is to save time and to get better ideas, I think that in practice we will spend more time on the bureaucracy and will get the same set of ideas. We are not short on proposals for changes to Go 2; that is not the bottleneck. Also, issuing an FRFP might tend to constrain proposals to the areas we state, rather than encouraging a broader range of ideas. Thanks, but we aren't going to adopt this procedure.

Note that the Go team introduced a second proposal process with the Go 2 Draft Designs.

The proposal above offers a constructive critique of that process. I hope you'll review its suggestions before releasing new Draft Designs. Thanks for your consideration.

cc @rsc @griesemer @bradfitz @robpike

@networkimprov The Go2 Draft designs do not constitute a new proposal process. They are draft designs that may eventually fold into the respective proposals for generics/error handling, etc. Those proposals comprise very large design domains, so we need a place to play with those designs outside the respective issue.

@griesemer I realize that a new process wasn't your intent. But the Draft Designs prompted a flood of detailed counter-proposals, apparently because many perceived them as RFPs.

Hence my suggestions re definition of RFPs.

I agree that the draft designs led to a batch of new proposals, but we already had quite a few proposals in all the areas addressed by the draft designs. We looked at those proposals in developing the draft designs.

@networkimprov Understood. Again, we really do want the proposal process to remain as light-weight as possible and thus fairly informal - that's the best way for the Go Team to be able to keep up with the proposal load (the more there is to read, the lower the chances it gets read quickly, or read in detail). It also requires the least amount of work for somebody who wants to propose an idea, which seems like a win-win to me.

The generics and error handling proposals touch many aspects of the language and are large, hence the more detailed design drafts which were created much after significant interest was expressed. Still, we don't want them to have to comply with some RFP process or form - it would mostly add an extra layer of work for little benefit. Making the feedback/comment process more formal also doesn't really help - at the end of the day we still just have to read the feedback.

If I may suggest anything to potential proposal writers it is to keep it short and concise. If you believe you have a good idea, start with a couple of paragraphs explaining the idea, and only if there is significant interest, go about and expand on it. And even then, expand only as far as necessary or requested. Turn-around will be quicker because it's easier for everybody to read a short snippet than a long exposition. There is no "higher chance of acceptance" simply because the proposal text is expansive.

Thanks.

I don't wish to belabor this, and I follow your rationale, but I gather from the feedback that this was missed:

A Draft Design (or RFP) should always:
a) describe a problem of current practice
b) summarize relevant experience reports
c) identify functional requirements

(c) is missing in the Go 2 Error Handling docs, for example. BTW, I undertook to fill the gap, and posted about it on golang-dev -- but that's another matter.

I hope this helps.

@networkimprov Thanks for this. The problem with c) is that it's highly subjective, of course. But I agree that it would be helpful to narrow the proposal space. I'll make sure a refined error design draft will incorporate it.

Glad to hear it!

I'd welcome any discussion on the golang-dev thread I linked.
The latest edition of my requirements catalog is here:
https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a