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 <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/ba9d8941-1ce4-40c0-bd0e-5dc22241ebecn%40googlegroups.com.
