Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 11:13 AM 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
>>  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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXEZiyW%3D0imRBAej0wf8E78j_dScOZLTOzj82WVX0%3DC6g%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[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 schrieb am Freitag, 17. Juli 2020 um 19:54:46 UTC+2:

> On Fri, Jul 17, 2020 at 10:20 AM 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+unsubscr...@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.

Re: [go-nuts] Go 2 review process

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

On Mon, Jul 20, 2020 at 10:54 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
>  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.
>
> --
> 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+unsubscr...@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
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGe8nGETDFLXyjJgfc3EOnhathv5TNsn_2K3Ro4K3p6sc1ctAg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

['Axel Wagner' via golang-nuts]

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 :) )

On Mon, Jul 20, 2020 at 5:48 PM David Skinner 
wrote:

> 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
>
>
> On Mon, Jul 20, 2020 at 6:01 AM Markus Heukelom 
> 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?
>>
>> 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:
>>
>>> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett 
>>> wrote:
>>> >
>>> > 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?
>>>
>>>
>>> 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
>>> 

Re: [go-nuts] Go 2 review process

[Jan Mercl]

On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
 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.

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

Re: [go-nuts] Go 2 review process

[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


On Mon, Jul 20, 2020 at 6:01 AM Markus Heukelom 
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?
>
> 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:
>
>> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett 
>> wrote:
>> >
>> > 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?
>>
>>
>> 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
>> 

Re: [go-nuts] Go 2 review process

[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:

> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:
> >
> > 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?
>
>
> 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
>

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

Re: [go-nuts] Go 2 review process

[Tyler Compton]

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

On Sun, Jul 19, 2020 at 4:12 AM Ian Davis  wrote:

> On Sun, 19 Jul 2020, at 2:08 AM, Ian Lance Taylor wrote:
> > On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton 
> 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.)
> >
>
> 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
>
> --
> 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+unsubscr...@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
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3J%3Dfg9WxCfODoJ7NUagXfqm8e7SkgFVNNSOkAFd4Bazg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Ian Davis]

On Sun, 19 Jul 2020, at 2:08 AM, Ian Lance Taylor wrote:
> On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton  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.)
> 

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

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

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUkjy0Q_eD19Jn3%3D%3DJccXiN6Zh56XwStSLwkXa1xDuwqg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

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

On Saturday, July 18, 2020 at 4:05:18 PM UTC-5 Randall Oreilly wrote:

>
> > On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor  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
>
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on 

Re: [go-nuts] Go 2 review process

[Randall Oreilly]

> On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor  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



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/73C21F61-EC5E-4649-A3C8-61354317A005%40colorado.edu.

Re: [go-nuts] Go 2 review process

['Axel Wagner' via golang-nuts]

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 :)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHrs-wztwHWsze4dyK95PqckqYeCPfkb5%2B0Y0abGZmNSg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

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



On Friday, July 17, 2020 at 7:54:46 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Jul 17, 2020 at 10:20 AM 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/25f267d8-9d90-4a92-9435-04c5d958dc0do%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[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  wrote:

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1KjOU0tzp_nWpV1a_qcFF3XNXs5AB4gsavhtHHPzmz9w%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 10:20 AM 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXterzGR2QekJjQaVX-RNYaraQrW35eXm-tiz%3D4z2JoqQ%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 5:40 AM 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


> On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:
>>
>> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:
>> >
>> > 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?
>>
>>
>> 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
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on 

Re: [go-nuts] Go 2 review process

[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 

 
giuliom...@gmail.com schrieb am Freitag, 17. Juli 2020 um 14:39:55 UTC+2:

>
> 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
>
> On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:
>
>> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  
>> wrote: 
>> > 
>> > 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? 
>>
>>
>> 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 

Re: [go-nuts] Go 2 review process

[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

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

> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:
> >
> > 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?
>
>
> 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
>

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

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:
>
> 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?


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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUrrDsHtmOJYr0vGaypFFAhhcfGdvDk9gh1SODeoZKYGg%40mail.gmail.com.

[go-nuts] 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

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