ahh let me rephrase, What I am proposing is removing the requirement for sign-off when submitting a native module to the package repo. These packages would be considered 'unofficial' by default. To make them 'official' would require the existing sign-off. Packages from elm-lang would all be considered 'official'.
Each of these packages could then have their own PR approval process which would allow for the experimentation that I talk about. Elm-lang would continue to have its existing PR process until its determined that a better approach should be taken (hopefully based on the results of PR experiments from the un-offical modules). On Friday, July 15, 2016 at 11:33:55 AM UTC-7, Nick H wrote: > > OK, thank you for clarifying! > > Submitting a PR to the official libraries is a very different thing to > submitting a native module to the package repo. I don't think that the > process you are proposing would make any sense for PRs to elm-lang. > > - They are official libraries, so putting an "unofficial" disclaimer on > bits of them would be confusing. > - What do you envision the PR approval process to look like? It sounds > like you are suggesting that all PRs be approved automatically. > > > On Fri, Jul 15, 2016 at 11:13 AM, Justin <greye...@gmail.com <javascript:> > > wrote: > >> 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> 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. >>>> 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...@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.
