> > 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? > Thanks for letting me know, I am talking about both the official elm-lang libraries and anything that needs approval to be published to the package repo (any Elm package with native js code, which from what I can tell are mostly non-existent outside of elm-lang packages in 0.17, an old example would be elm-console <http://package.elm-lang.org/packages/laszlopandy/elm-console/1.1.1/>).
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? I was hoping to communicate here that this is an advantage, now different approaches can be taken to solve the problem (and existing approaches can be remixed) and the best approach can be rolled into the official elm package (which in this case would be http://package.elm-lang.org/packages/elm-lang/navigation/1.0.0/). thanks for reading! On Friday, July 15, 2016 at 10:46:18 AM UTC-7, Nick H wrote: > > 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 <greye...@gmail.com <javascript:> > > 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 elm-discuss...@googlegroups.com <javascript:>. >> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
