Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: establish RFP/RFC process for language feature proposals #29860

Closed
networkimprov opened this issue Jan 22, 2019 · 19 comments

Comments

@networkimprov
Copy link

commented Jan 22, 2019

Go 2 Language Change proposals for new features are accumulating steadily, and consuming time on the part of the Go team and proposal proponents. (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.)

Those of us interested in proposing or discussing new language features would benefit from guidance by the Go team regarding which sorts of features have priority, and which are off the table, having been considered and discarded. And detailed guidance about priority features could leverage the whole community for development of comprehensive proposals.

Therefore I'd like to suggest creation of a process that defines Language Feature Requests for Proposal & Requests for Comment, aka FRFPs & FRFCs. The Go team would issue FRFPs (describing problems of current practice, experience reports, and functional requirements) to solicit design concepts from the community. The Go team and community members would publish FRFCs (describing semantics, syntax, and use cases) to present design concepts for discussion and development.

Rust, for example, has an extensive RFC process. In contrast, the current Go proposal process and template make hardly any demands on proposal authors, forcing readers to engage in discussion just to understand a proposed concept.

EDIT: Inviting the community to submit FRFCs to fix widely-discussed problems is a community building exercise, especially where the result is adoption of a concept originating outside the Google team.

Documentation of the FRFP/C process would cover:
a) required elements in each type of document,
b) the stages that precede and follow publication,
c) where the documents are published and indexed,
d) what forum carries discussion of them, and
e) authors' duties regarding feedback.

Briefly, I'd imagine the following: Both types of document should be discussed via golang-dev, and discussion should begin before publication. FRFPs should be covered on the Go blog when published. Both types should be linked from wiki pages curated by the Go team, and committed to the Go proposal repo. If an FRFC reaches the draft implementation stage, an issue should be filed on the github issue tracker.

An FRFC that addresses an FRFP could be fairly short; the first draft might be a collection of commented code samples. An FRFC that doesn't address any FRFP would have to provide key elements of an FRFP, e.g. real-world examples of how existing practice falls short, and an outline of potential requirements for any reasonable solution (including points that the author chose not to address in their design concept). FRFCs of this type might prompt the Go team to draft an FRFP in response.

I'd also suggest that this process be applied to the Error Handling and Generic Programming features, which would mean reorganizing the Draft Design documents into FRFP & FRFC docs, and adding to each as necessary to meet the specifications of the newly-defined process.

This process could apply to other areas central to the Go ecosystem, e.g. tooling. It would probably not apply to minor language adjustments (e.g. #19113 & #19308) or stdlib proposals, which are by definition more modest in scope and impact than new language features.

@gopherbot gopherbot added this to the Proposal milestone Jan 22, 2019

@beoran

This comment has been minimized.

Copy link

commented Jan 22, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

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.

@beoran

This comment has been minimized.

Copy link

commented Jan 22, 2019

@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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

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.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 22, 2019

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

gopherbot pushed a commit to golang/proposal that referenced this issue Jan 22, 2019
README: mention current Go 2 process
Updates golang/go#29860

Change-Id: I442ed5d8d5bfe26abdfc93059b1c57b09fb00c8a
Reviewed-on: https://go-review.googlesource.com/c/158843
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@networkimprov

This comment has been minimized.

Copy link
Author

commented Jan 22, 2019

@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 ianlancetaylor changed the title proposal: Go 2: Establish RFP/RFC process for language feature proposals proposal: Go 2: establish RFP/RFC process for language feature proposals Jan 22, 2019

@beoran

This comment has been minimized.

Copy link

commented Jan 23, 2019

@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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2019

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.

@networkimprov

This comment has been minimized.

Copy link
Author

commented Jan 31, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

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.

@networkimprov

This comment has been minimized.

Copy link
Author

commented Feb 26, 2019

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

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

@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.

@networkimprov

This comment has been minimized.

Copy link
Author

commented Feb 26, 2019

@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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

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.

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

@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.

@networkimprov

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

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.

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

@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.

@networkimprov

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.