I must add these here: 1. https://www.youtube.com/watch?v=0Zbh_vmAKvk 2. https://www.youtube.com/watch?v=wpHggcP-L5M 3. https://blog.golang.org/toward-go2
Core team is asking for "Experience Reports"... which are not the same as "Feature Proposals". Many of the proposals I've noticed come without proper context and backstory -- in other words, why they were proposed in the first place. This already halts the problem solving and eliminates a ton of alternate solutions for the "unsaid problems". It's difficult to evaluate proposals without Experience Reports with regards to their possible value in practice. In some cases, there might be an elegant solution for the particular problem in Go that the proposer might not be aware of. In other cases, the initial code might be flawed making the proposal unusable. IMO, the main contributor of disagreements are 1. problem domain, 2. experience of different domains and 3. disagreement of values. Values are indirectly built-out-of 1. problem-domain and 2. experience of different domains. As such, without proper problem-domain and real-world-examples it's difficult to come to an agreement about a solution. Unfortunately, people usually aren't aware of the things they have picked up over time... be it starting with getting extreme diligence from assembly, or extreme concision in APL; complexity of distributed algorithms, playfulness of statistical analysis or speed of iteration from developing games. It's also problematic that many of these skills or systems seem "so-obviously-related-to-the-particular" problem at hand... which means, people leave them out. Other people of course imagine their own problems and situations... which leads to different "optimal solution" and disagreements and long-winded discussions, where people do not understand each other and try to convince each other. tl;dr; try to include your problem-domain and real-world-examples in discussions, so people can understand you. + Egon On Monday, 21 August 2017 20:03:15 UTC+3, JuciÊ Andrade wrote: > > If you guys allow me, I have a little concern about the Go 2 process. > I perceived some harsh debates when someone propose a new idea. That is > not the proper attitude. Please consider that the core team explicitly > asked for new ideas. > As a comunity we are used to deny the value of some novel propositions. > Conservatism is part of our culture. Usually the bar is very high to change > anything. > For Go 2 project to succeed, however, we should change that attitude for a > while. Now is time to allow people to complain, say whatever they want, > propose otherwise crazy ideas. Let's leverage that, let's appreciate a > differing point of view, a non obvious workflow, a strange idea. Let's keep > our ears open and our critical mouths shut. In due time critical assertions > will be welcome. > Keep in mind that not everyone in this list is a native English speaker. > Sometimes it is difficult to chose the right words. We don't want to loose > a good idea for a minor detail. > And, above all, let's keep polite. > -- 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.
