And I forgot to mention a key point:
There must be a separation of problems and solutions. It is critical as the problems are personally experienced out of necessity. Solutions, alternatively, need to remain independent of any individual so they can be evaluated objectively. We can and *should debate and criticize solutions* to ensure that we have the right solution for the problem at hand. We *should not criticize experiences* nor are any of us in a place to. Each of us are entitled to our own experiences and are free to share them from our own perspective without fear of criticism or condemnation. On Tuesday, August 22, 2017 at 5:21:36 PM UTC-4, Steve Francia wrote: > > As one of the few people who participates in the proposal review meeting I > thought I'd shed some light on this. > > Go is intentionally simple. A lot of work has gone into the small balanced > set of features. In fact prior to 1.0 a good number of features were > removed as they weren't needed. > > The statement "As a community we are used to deny the value of some novel > propositions." is just not true. It's not true about the community as a > whole and it's not true about the project leadership. > > With each proposed feature we weigh the value of that feature vs the cost > of adding it. We consider many costs including the cost to implement the > feature, but also the cost of complexity, the cost of education and the > cost that comes from transitioning to a new change. In many cases the value > provided simply doesn't outweigh the costs, sometimes it does, but the Go > project leadership never denies the value of any proposition. > > To make another clarification, in his keynote Russ both announced Go 2 as > well as defining the process by which technical decisions are made for the > Go project. The process outlined is not "the Go 2 process" but rather our > process for developing Go and it applies to all future versions (including > Go 1.10). > > Now to address some of the feedback in this thread: > > First, please read and re-read the blog post > <https://blog.golang.org/toward-go2> on this. A lot of time and thought > went into both writing that post as well as the process it conveys. Many > things have been said that show a fundamental lack of understanding of that > post. > > I want to call out a specific part of this post. While they are called > "experience reports", what we are looking for is more specific than just > experience. > > > Step 2 is to identify a problem with Go that might need solving and to > articulate it, to explain it to others, to write it down. > > What is absolutely essential is that there is 1. a written *report* 2. > that identifies *a problem* 3. that *the author is experiencing* 4. *with > Go*. > > If it doesn't have those 4 components, then it isn't an experience report. > > Without an experience report accompanying it, a proposal lacks grounding. > > > -- 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. For more options, visit https://groups.google.com/d/optout.
