On Fri, Jul 17, 2020 at 5:40 AM giuliom...@gmail.com <giuliomichel...@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 <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. -- 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/CAOyqgcX--JK%2BCxDNvnmeSUAzpNgabURmT-kkvSjJCOQTLkhXUA%40mail.gmail.com.
