> > I define core here to be any project with native Elm code and the compiler.
I am afraid I don't understand this definition at all. Are you talking specifically about the official elm-lang libraries? Or are you using it as a synonym for the package repo? The example problem you describe under "Why?" -- four different packages that do routing in different ways -- How would this situation be any different if people could submit native code? On Fri, Jul 15, 2016 at 10:25 AM, Justin <[email protected]> wrote: > This is a continuation of this > <https://groups.google.com/forum/#!topic/elm-dev/VVhf-oF6OHE>discussion. > Posting in elm-discuss instead of elm-dev based on this > <https://groups.google.com/forum/#!topic/elm-dev/oZ3xW_nMPNo>. > > Through this discussion I have realize that the way I define collaboration > on the core Elm projects is not the same as others. > I define core here to be any project with native Elm code and the compiler. > > Here is my understanding about how contributors have collaborated on the > core in the past, > 1. Evan hand verifies every PR to core and native module publish request > (this was described as very time consuming and expensive). > 2. A group of community members were self elected to hand verify native > module publish requests (this was described as not being effective and > encouraging bad behavior). > 3. others approaches? > > *Here is my proposal,* > Allow the publishing of any native module to core but with explicit > warnings and tagging that they are not an 'official' native module and > unsupported by Evan/elm-lang. > > *Why?* > *Share and Remix other peoples work* > When I say collaboration for a globally distributed population of > developers I am talking about the ability to share and remix other peoples > work. You can do this today with Elm only packages and as a result you can > see different approaches being taken for specific problems. For example go > to http://package.elm-lang.org/ and search 'routing', four results pop up > all for solving URL parsing with slightly different approaches and > functionality. > > Arguably this is both the best and worst part of NPM (node package > manager). It provides incredible power to remix and share JavaScript with > others but also leads to the problems Evan described in this blog post ( > http://elm-lang.org/blog/farewell-to-frp under the Web Sockets section). > That is why in this proposal I am arguing for separating out the 'official' > and 'unofficial' native module packages as it would allow for remixing and > also (hopefully) for the best ideas to make there way back into the > 'official' versions. > > Another way of describing this is that it helps Elm avoid local peaks, > Peter Hintjens describes it much better then I can in chapter 5 of his > book > <https://hintjens.gitbooks.io/social-architecture/content/chapter5.html> > under the "Simplicity Oriented Design" section. > > For example if someone remixes another's module to add some new > functionality, well maybe the approach they took was not very 'Elm like'. > Then someone else can work off of what they did and lead to a more 'Elm > like' solution. Some time later Evan is working on adding that same > functionality into the official packages, he can take advantage of the work > others have done already to understand what the best approach might be > holistically. > > *Process Experiments* > I also would argue that this would allow for process experimentation for > the 'unofficial' native modules without causing pain to Evan and > interrupting the main development pipeline. When I say process here I mean > essentially the collaboration agreement, how does work get done for the > project. For those that land on excellent solutions the process behind them > can be shared to hopefully lead to smarter less risky process experiments > for the official modules. > > Why do I think this is important? Well from what I have seen Elm has > struggled in allowing the community to contribute to the core. What is > frustrating (for me) is that there are actually dramatically different > approaches to how to run open source projects that lead to happy > communities and fantastic solutions. The main argument I have seen against > experimenting with different approaches is that it will be expensive and > will slow down the development of Elm over all. With this approach the > possibility of experimenting with different approaches becomes much cheaper > as it won't affect the current core development and will hopefully save > time in the long run as pitfalls will already be uncovered and great > solutions will be discovered. > > The final point I want to discuss is that of code quality. One of the > points brought up for the current approach is that it is the fastest way to > ensure high code quality in the native module JavaScript. JavaScript not > guaranteeing referentially transparent code, and run time exceptions are > both of primary concern. Allowing for 'unofficial' modules would also allow > for experiments in other approaches to writing 'high quality code'. > > As and aside when measuring code quality I usually look at bugs, count of > active bugs, time to fix, fix rate, and injection rate. Overall the metric > I general have seen to be effective (if applied with the right supporting > pressures) is average bug age. If the average bug age is low then all of > these metrics have to be trending in a good direction (less bugs overall, > fast time to fix, and lower injection rate). Its hard to cheat this metric > as if you are making crappy fixes then your bug rate is only going to go up > and your time to fix is going to only get longer. Of course this metric is > usually a little slow in reacting to the code quality so the general > approach I have seen to be effective is that you want the Average Bug Age > to be ~1% better every week until you reach zero bugs by 2 years. When I > say bug what do I mean? Ideally a bug is anything that disappoints or > surprises anyone, although in many cases you have to purposefully narrow > the definition when you have a lot of bugs (for example my team at work > right now says a bug is "an unexpected regression in behavior or > performance" or more commonly know as a regression). From just glancing > over the Elm core projects there are many bugs (FYI not all issues are > bugs) that are very old (3+ months)... Yes Elm is trying to provide great > run time guarantees and that is one of the reasons I am very excited by it > and have enjoyed developing with it but when I find a bug and it takes 3+ > months to fix, that to me comes across as Elm is not at the quality level > it is striving to be at. > Lots of supporting readings on this, here are a few > http://arlobelshee.com/treat-bugs-as-fires/ > http://jbazuzicode.blogspot.com/2015/02/bug-metrics.html > > http://jbazuzicode.blogspot.com/2016/02/bugszero-agile-open-northwest-2016.html > http://jbazuzicode.blogspot.com/2016/04/definitions-of-zero-bugs.html > > > Thanks for reading and your consideration! > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
