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 <markus.heuke...@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? > > 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 <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 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/29cad39d-caa3-4315-bedc-bea3a02dc10dn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/29cad39d-caa3-4315-bedc-bea3a02dc10dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGe8nGGJ_ft9LgwLHnefjx4BO%2BOakNTy6Lh5xPOsFXXEhLqVow%40mail.gmail.com.
