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 <ben...@gmail.com> 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.
