Go 2 review process

[Brandon Bennett]

I have just read https://github.com/golang/go/issues/33892#issuecomment-659618902 and since it was posted on a closed issue I wanted to comment a bit more.

I subscribed to this issue and read the updates for both the Go2 proposals as well as the Go1 proposals and I enjoy reading them.  I understand the reasoning behind wanting to do less here but I do belive there are some downsides as well.

One reason I read these every week is that it gives people outside of the Go team an insight into the thought process and the reasoning of decisions.  Also feedback on these changes hopefully should help to refine future requests.  I am really afraid that just "ignoring" requests continues or goes back to the idea that  that Go is not a community language and that the only ideas and changes can come from Google employees (or past employees in the case of bradfitz).  The transparency here was awesome and I am very sad to see it go away.

I hope there is some other middle ground or at least some details around what will go into hand picking?  For the non-picked proposals will they just remain open for some undetermined amount of time?  Will they just be closed?  Is feedback on these still expected?   Maybe the real solution is just to meet up less?  Maybe once a month or even once a quarter vs every week?

Thank you,

Brandon

[Ian Lance Taylor]

I think one way to describe what is happening is our growing awareness
over time that most language change proposals don't bring enough
value. The language is stable and is not looking to change in any
significant way (except perhaps for adding generics). We've realized
that we need to be upfront about that. What has been happening with
language change proposals is that we say we don't see enough value,
but naturally the proposer does see value, and often is not happy
about our comments. Then we get into an uncomfortable discussion
where we say no and the proposer says why not. This leads to hurt
feelings and no useful progress, and we certainly don't feel good
about it ourselves. For example, just to pick on one perhaps
unfairly, see https://golang.org/issue/39530.

I agree that feedback should ideally help to refine future requests,
but after a couple of years of feedback I see no evidence that that is
happening. Maybe our feedback is bad, but I also suspect that part of
the problem is that most people who want to suggest a language change
don't read the earlier feedback. Or perhaps the ones who do just
don't go on to propose a change after all. I can certainly understand
not reading all the feedback; there are 89 issues just on the topic of
error handling alone, some of them quite long. But it follows that I
can understand that the feedback isn't helping much.

This doesn't mean that there will be some other process for making
language changes. It's still the same process. There is no special
route for Google employees (and most proposals by Google employees are
rejected, just like most proposals by non-Google-employees). What it
means, I hope, is that more changes will be rejected more quickly and
with less back and forth discussion.

One observation that led to this change is that often we would look at
a proposal and immediately say "well, this one is not going to be
accepted." But then it would take us 30 minutes to explain why, and
then we would spend another few hours over the next few weeks replying
to comments. But the fact was we knew in 30 seconds that it wasn't
going to be accepted. It may sound blunt, but I think it will be a
net benefit to the overall ecosystem to spend just 1 minute on that
kind of proposal, not several hours over time.

Hope this helps. Happy to hear comments.

Ian

[giuliom...@gmail.com]

I believe this is an important part of the community, without such process, we would not get new smart ideas for Go. I don't know exactly the rejection rate, but even if it was 1 accepted idea out of 100, all of them must be reviewed in order to spot the right one. 

On the other hand, I understand your point and the reason why the review approach has changed. I personally think it makes perfectly sense.

However, how can we make sure that we don't miss smart ideas for Go 2? I guess that someone must still to spend their time in reviewing and selecting.

Thanks

Giulio

[medienwer...@gmail.com]

Dear Ian

With your considerations in mind I suggest a well defined triage mode/"traffic light" - system for processing language feature proposals. 

When your/the teams bias is clear, the indication shows the proposer/the community feasible and/or practicable "next steps".

Also a collection of "reference cases" can guide the growing number of gophers, viable ideas and solutions.

Following posts explain the needs:

https://blog.golang.org/toward-go2 

https://blog.golang.org/experiment  

https://blog.golang.org/go2-here-we-come 

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 5:40 AM giuliom...@gmail.com
<giuliom...@gmail.com> wrote:
>
> I believe this is an important part of the community, without such process, we would not get new smart ideas for Go. I don't know exactly the rejection rate, but even if it was 1 accepted idea out of 100, all of them must be reviewed in order to spot the right one.
>
> On the other hand, I understand your point and the reason why the review approach has changed. I personally think it makes perfectly sense.
>
> However, how can we make sure that we don't miss smart ideas for Go 2? I guess that someone must still to spend their time in reviewing and selecting.

We'll still read all the proposals.

Ian

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/61a2e91a-8505-4a45-976f-3813d59ca746n%40googlegroups.com.

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 10:20 AM medienwer...@gmail.com
<medienwer...@gmail.com> wrote:
>
> With your considerations in mind I suggest a well defined triage mode/"traffic light" - system for processing language feature proposals.
>
> When your/the teams bias is clear, the indication shows the proposer/the community feasible and/or practicable "next steps".
>
> Also a collection of "reference cases" can guide the growing number of gophers, viable ideas and solutions.
>
> Following posts explain the needs:
>
> https://blog.golang.org/toward-go2
>
> https://blog.golang.org/experiment
>
> https://blog.golang.org/go2-here-we-come

Thanks for the suggestion. However, I don't understand how to make
that work in practice. Who is going to take the time to show feasible
and practical next steps for each proposal? How is that different
from what we have been doing for the last year?

Ian

[Tyler Compton]

I'm beginning to think that community members (like myself) can't reasonably be expected to put in the necessary effort to champion a sizable language change. I think it was Ian who made multiple generics draft proposals just to reject them himself, then Ian and Robert Griesemer spent more untold hours writing the contracts draft design only to have that rejected as well. For people outside the core Go team, these probably would have been unpaid hours. It's hard to justify spending that kind of time when there's such a high chance that the proposal may not amount to anything. I think it's for this reason that community proposals are usually nowhere near as fleshed out as the draft proposals we've been getting from the core team.

There are some incredibly talented and persistent gophers out there and I don't mean to discourage them. This is just my observation from the community proposals I've read.

On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett <ben...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6e012c05-24ce-49cf-a8f2-b8b6f3f543ffo%40googlegroups.com.

[Max]

I have a proposal for improving Go proposal procedure.

It stems from two "issues" highlighted in several occasions:

1. core Go team is spending an increasing amount of time discussing a larger number of proposals.
   All of them are commented and discussed by core Go team, and in the end most of them are declined.
   
   
2. participation of Go community at large to the proposal procedure is limited:
   single individuals can create new proposals or comment on them, but there is no concept of "community support" or "community effort"

In short, there is no *filter* between single individuals and core Go team.
Direct communication is good in a small group, but it does not scale to large groups.

My proposal is conceptually simple:
    delegate some power (rights) and responsibility (duties) to the community.

How? I propose the following:

1. proposals must collect enough "community support" before being evaluated by core Go team.
   Initially, this can be as simple as waiting for enough thumbs up (and fewer thumbs down) on the corresponding github issue.
   If/when need arises, it may also become a more formal process.

   The core Go team will have less work:
     they would be *required* to evaluate only those with enough "community support", not *all* proposals as they do now.
     Of course they will still be free to evaluate also other proposals if they want, but they will not be required to.

   The Go community would be empowered by this change:
     it will have a more active role, acting as a first filter for proposals,
     and a proposal with strong community support should receive more focus from core Go team
     than a proposal with weak (or no) community support.

   This may require a web page that lists active proposals (is it allowed to scrape github content?),
   with mechanisms to filter them by keyword(s) and sort them at least by date/thumbs up/thumbs down.

2. proposals must follow a template, which contains at least:
 
   a. the list of existing similar proposals and, if they were not approved, the reasons why the new proposal
      is believed to be better
 
   b. a first evaluation of pros and cons

   This is expected to improve the quality of new proposals, by doing a basic background check of prior art
   and a first (self) evaluation.

[Axel Wagner]

There seems to be an assumption that, given enough time and effort, any idea could get accepted into the language. But that clearly can't be so. It might be frustrating to hear that your particular idea just isn't considered a good idea, but it's a necessity that most ideas go that route. It's not a question of how much you flesh it out or how much developmental feedback it gets - most ideas just won't end up in the language.

I think so far the Go team has done an incredible job at triaging and discussing any idea, even if I felt it clearly wouldn't make it. I totally understand if they are being more direct and brief in the future :)

[Randall Oreilly]

> On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor <ia...@golang.org> wrote:
>
> The language is stable and is not looking to change in any
> significant way (except perhaps for adding generics). We've realized
> that we need to be upfront about that.

The Go2 process certainly created the expectation that the language was looking to change. But I guess the point here is that this window is now closing? Maybe it would be good to have a new blog post to that effect?

Expectation management is very important -- if we all recognize and accept that Go is a fixed language that will never change, then nobody will be disappointed when it doesn't!

And why should it change? This idea that languages should constantly be evolving may not make any sense: once a language is Turing complete, and highly effective, supporting millions of happy, productive coders, it could just be done. People can invest time and energy in writing code and tools, not changing the language.

I guess the only two major pain points that are widely discussed are generics and error handling, and it looks like we'll get a good solution for the first, and who knows about the second at this point?

Maybe the ONLY allowed issues going forward should be experience reports and clear identification of problems / pain points (which have always been requested, but are probably the minority of user contributions?), and maybe some process for community input / voting for how significant those issues are (as Max suggested).

- Randy

[David Skinner]

While I have over 50 years of programming experience, I am also quite old and sometimes have senile moments.

I once wrote an extremely well-written bug report complaining about the use of the backtick which is not on my keyboard, explained why it should not be used, and then presented a workaround involving ANSI escape codes to enter the character which was not on the keyboard. The response was immediate and quite positive as everyone thought it was a marvelous satire on newbies who suggest language changes without understanding Go first. However, my eldest son Daniel, called me on the phone to remind me that the backtick was in fact on my keyboard just below the ESC key. He also asked me not to comment on Go-nuts on a bad day.

Anyone who does not like a Go syntax can do what I do, I write my code the way that I write code in Davsk, then I compile/refactor that into Go code. I have enum, ternary, generics,  whatever I want but the implementation is in Go. I am someone who does not believe in writing a lot of code, I prefer to do a domain-specific definition of a problem and then compile my definition into implementation, and the implementation in Go is performant and adequate.

The disadvantage of my approach is that I am using the same high-level language I used 40 years ago. Great for me, bad for everyone else.

The Go2 preprocessor that lets you test generics syntax is precisely the kind of solution that I approve of, but we cannot have a plethora of standards or we lose readability. GOFMT was a godsend for standardization even if I did not agree with all of the decisions, someone had to make the decision and then the decision had to be enforced.

I need for Go to remain standard and unchanging, fast when compiling and linking, fast when running, small footprint, cross-platform, not because I use it to write my programs, but because I use it to compile my programs which some else who does understand go will be able to comprehend.

The generic proposal with a plethora of ()()() resulted in a stack overflow for my parser which is implemented in wetware, my eyes saw it all but with or without spaces, just not intuitive in my brain, it lacks readability. Code is written once, read many
I prefer the Clojure method of handling generics, I do not mind <>, not sure about [], gen keyword is a favorite for me. I can adapt to whatever the community decides. 

Error handling can certainly be cleaner but what we have so very versatile, I would hate it if you broke my old libraries. 

"Maybe the ONLY allowed issues going forward should be experience reports and clear identification of problems/pain points (which have always been requested but are probably the minority of user contributions?), and maybe some process for community input/voting for how significant those issues are (as Max suggested)."

I am totally in favor of the Go team making the final decisions, they have my respect and trust. But of course, the real final decision is made in the marketplace by the developers who choose to use or not use the language.

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton <xav...@gmail.com> wrote:
>
> I'm beginning to think that community members (like myself) can't reasonably be expected to put in the necessary effort to champion a sizable language change. I think it was Ian who made multiple generics draft proposals just to reject them himself, then Ian and Robert Griesemer spent more untold hours writing the contracts draft design only to have that rejected as well. For people outside the core Go team, these probably would have been unpaid hours. It's hard to justify spending that kind of time when there's such a high chance that the proposal may not amount to anything. I think it's for this reason that community proposals are usually nowhere near as fleshed out as the draft proposals we've been getting from the core team.

In fairness, though, there is no language change proposal that is as
large as generics. The changes that were made in recent releases were
much smaller. (And, for what it's worth, they did not all come from
Googlers; e.g., https://golang.org/issue/12711,
https://golang.org/issue/19308, https://golang.org/issue/29008.)

Ian

[Ian Davis]

I think the multidimensional slices proposal (https://github.com/golang/go/issues/6282 and several spawned from there) is an example of a major proposed change that the community put great effort into with multiple detailed specifications. There is an asymmetry of time and expertise at play here. I suspect many people would use and benefit from native matrices in Go but the number of people with the necessary skills to design the spec and the amount of available time to devote to it is vanishingly small.

We need a way for knowledgable experts to be able to take a sabbatical or similar to spend time refining and guiding their proposal with the Go team. Is this something that the Go project or another corporate sponsor could help with?

Ian

[Tyler Compton]

I had forgotten about the multidimensional slices proposal. That's a very good counter-example.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/37ed3f4e-460f-48b6-a636-61d3eadc5c8a%40www.fastmail.com.

[Markus Heukelom]

Would it be an idea to allow people only to label something as proposal if they have at least some support / voucher for the idea? Say N>10 general upvotes or 1 upvote from a golang committer? 

By allowing the "proposal" label, you sort of give people the idea that their idea will be "triaged", to which they then can "appeal". That is in fact very generous. Maybe it is better to only allow a "rfc" label (request for comments). That way you could post your idea, get feedback from the community (including golang fulltimers),  but there's no implied expectation whatsoever to the golang fulltimers to give a go/no-go for the idea. 

On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:

[David Skinner]

I really like Markus Heukelon's suggestion.

There is no need for the Go team to evaluate each proposal, that is a silly waste of a valuable and limited resource.
Having a list of all proposals with voting means that the most popular items float to the top and the worst float to the bottom and newbies can learn more about the language by reading the list and the comments. We can let the community at large do the triage. We can also weight the votes based on experience and expertise so:

• Newbies get one vote.
• Devs like me get 5 votes
• Daniel Skinner gets 10 votes.
• TODO(?) Insert Names of other famous people on the go team.
• Rob Pike gets 1,000 votes

# List of All Proposals +

• Proposal #1. Use ternary. Up: 27 Down: 5,362

condition ? value_if_true : value_if_false
## Comments

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Zqu-HZh3lFg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/29cad39d-caa3-4315-bedc-bea3a02dc10dn%40googlegroups.com.

[Jan Mercl]

On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
<markus....@gain.pro> wrote:
>
> Would it be an idea to allow people only to label something as proposal if they have at least some support / voucher for the idea? Say N>10 general upvotes or 1 upvote from a golang committer?

The problem is that not everyone has a Github account.

[Axel Wagner]

Hi,

ISTM that all those filtering-suggestions are quietly redefining the problem. The Go team didn't say "we don't have time to read all proposals", they said "we don't have time to argue every proposal in-depth". So if your concern was "that is bad, because I want all proposals to get enough attention", you are not actually helping those proposals - if it doesn't pass whatever arbitrary threshold you set will still not get an in-depth discussion. At the same time, you are making it nigh impossible for a proposal to gain traction, if it doesn't have broad audience appeal - even if it is a simple and strictly good idea. Lastly, there's still the possibility of a DoS-Proposal, if it gains some upvotes and people then insist on an in-depth discussion - even if it's pointless because the Go team is fully aware they don't want it.

So, IMO, these suggestions are the perfect compromise, in that they leave everyone equally dissatisfied.

(Also, just FTR, I really dislike formal governance solutions, especially based on votes, especially if "everybody gets one". In practice, that just devolves into "the loudest person gets their will" and I'm pretty loud and could do without that responsibility :) )

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGe8nGGJ_ft9LgwLHnefjx4BO%2BOakNTy6Lh5xPOsFXXEhLqVow%40mail.gmail.com.

[David Skinner]

Not having a GitHub account is a non-issue.

• It is an issue now because the enhancement process is on GitHub issues which does not include voting or weighting of votes.

It is a trivial matter to use gohugo.io with a package that integrates GitHub issues as the repository for comments.
---
But yes I am suggesting that the proposals be on a separate site or subdomain dedicated to the tracking, triage of enhancement requests. Approved enhancements get promoted to the GitHub issues as appropriate.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Zqu-HZh3lFg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-VS8vQVQr3AiFCX1OsgyeNYF4%2BY%2BFJ%3Dxu8_eATzRfk%3DFQ%40mail.gmail.com.

[medienwer...@gmail.com]

Dear Ian

re :  "However, I don't understand how to make
that work in practice. " 

from my research so far I found tons of Github Actions related to "Projects"...

just some examples: 

https://github.com/marketplace/actions/all-in-one-project

https://github.com/marketplace/actions/assign-to-one-project

https://github.com/marketplace/actions/github-projects-column-mirror

https://github.com/marketplace/actions/automate-projects

...

My proposal:

- you configure a public github project with columns ("proposal", "language change", "Go2", "Feature Request",...) that operates on golang organizational level; link it to go language repo!

-  the contributer files a "request" issue(just title, feature, subject; no details) in the go repo

- @settings/users of the public project you invite the contributor to drop a "proposal" note (maybe through github actions(?); this is the detailed contribution, proposal....!

- in the project columns you make the "triage" by editing the note and/or converting notes to issues ("RFCs") for tracking, label adding,...

let me work on the github actions side in the next couple of days; maybe I can figure out automation...

Regards

Matthias

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 11:13 AM medienwer...@gmail.com
<medienwer...@gmail.com> wrote:
>
> re : "However, I don't understand how to make
> that work in practice. "
>
> from my research so far I found tons of Github Actions related to "Projects"...
>
> just some examples:
> https://github.com/marketplace/actions/all-in-one-project
> https://github.com/marketplace/actions/assign-to-one-project
> https://github.com/marketplace/actions/github-projects-column-mirror
> https://github.com/marketplace/actions/automate-projects
> ...
>
> My proposal:
>
> - you configure a public github project with columns ("proposal", "language change", "Go2", "Feature Request",...) that operates on golang organizational level; link it to go language repo!
> - the contributer files a "request" issue(just title, feature, subject; no details) in the go repo
> - @settings/users of the public project you invite the contributor to drop a "proposal" note (maybe through github actions(?); this is the detailed contribution, proposal....!
> - in the project columns you make the "triage" by editing the note and/or converting notes to issues ("RFCs") for tracking, label adding,...
>
> let me work on the github actions side in the next couple of days; maybe I can figure out automation...

Thanks, but it's not the mechanical steps that are time consuming.

Ian

> Ian Lance Taylor schrieb am Freitag, 17. Juli 2020 um 19:54:46 UTC+2:
>>
>> On Fri, Jul 17, 2020 at 10:20 AM medienwer...@gmail.com
>> <medienwer...@gmail.com> wrote:
>> >
>> > With your considerations in mind I suggest a well defined triage mode/"traffic light" - system for processing language feature proposals.
>> >
>> > When your/the teams bias is clear, the indication shows the proposer/the community feasible and/or practicable "next steps".
>> >
>> > Also a collection of "reference cases" can guide the growing number of gophers, viable ideas and solutions.
>> >
>> > Following posts explain the needs:
>> >
>> > https://blog.golang.org/toward-go2
>> >
>> > https://blog.golang.org/experiment
>> >
>> > https://blog.golang.org/go2-here-we-come
>>
>> Thanks for the suggestion. However, I don't understand how to make
>> that work in practice. Who is going to take the time to show feasible
>> and practical next steps for each proposal? How is that different
>> from what we have been doing for the last year?
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/86ba57c2-7c82-4f0f-8a52-007c8ded6fd4n%40googlegroups.com.