├── README.md ├── history.md ├── maintainer_tips.md └── maintainers.md /README.md: -------------------------------------------------------------------------------- 1 | # elm-community 2 | 3 | Some `*-extra` packages that are fairly popular have come to live in `elm-community` over time. These existing packages are managed by the maintainer listed on those repos, but no new packages are added under the `elm-community` name. 4 | 5 | See [`maintainer_tips.md`](maintainer_tips.md) for rough guidelines on how to evolve `*-extra` packages. 6 | 7 | If you are curious about the archived repos under the `elm-community` name, check out [`history.md`](history.md) for some notes on how they got there. 8 | -------------------------------------------------------------------------------- /history.md: -------------------------------------------------------------------------------- 1 | ## History 2 | 3 | This organization was initially an experiment in code maintainance. Can **decentralized** people maintain packages over many years under a **centralized** GitHub organization? And can they do so without any funding for managerial overhead or for training and supporting new maintainers? 4 | 5 | ### Lessons 6 | 7 | The people who initiated this experiment ran into some rather predictable troubles and were not able to keep up with their initial vision. Over time it became clear that a more traditional approach (which has its own problems) would still work better overall. In the more traditional approach: 8 | 9 | 1. Packages are created by independent authors under their own name, like `alice/typed-svg` or `bob/easing-functions`. Authors run projects however they want, and the packages succeed or fail based on all the factors that go into that. Code quality, API design, blogs, docs, conference talks, etc. 10 | 11 | 2. If the needs of certain users do not match `alice/typed-svg` or `bob/easing-functions`, certain users can decide if it is worthwhile to make their own version and take on the full burden of development themselves. If it is not worthwhile to them, they will not do that. If it is worthwhile to them, they will do so under their own name and the package will succeed or fail on its own merits. Not by piggybacking on the reputation or usership of an existing package or organization. 12 | 13 | This is a **decentralized** way for **decentralized** people to end up with the code they want. There is no central point to ask permission for anything. And there is no official sounding organization that (with prior versions of this repo) might dissuade potential new package authors from pursuing their vision of a particular package. If your needs do not match what is freely available online, the next steps to solving your own problem are fully in your own hands. 14 | 15 | 16 | ### Current Usage 17 | 18 | No new projects are added, and existing projects are maintained as they always have been. 19 | 20 | So existing packages continue along as they are. If the existing maintainers take specific actions to fix bugs or add features, that is their perogative. If they want to add people to the repo, that is up to them. If someone with their own vision for one of these packages creates their own version, they should go for it and see how it goes. This way (1) there is no disruption in how any existing package works or will continue to work and (2) we will gradually switch back to a decentralized way of managing these projects to the extent that new packages provide practical benefits over existing ones. 21 | -------------------------------------------------------------------------------- /maintainer_tips.md: -------------------------------------------------------------------------------- 1 | # Maintainer Tips 2 | 3 | This document aims to lay out some guidelines for the maintainers of elm-community. 4 | 5 | ## Maintaining *-extra packages 6 | 7 | 1) Make sure that new functions have a purpose. If someone wants to make `takeTwo`, then make sure there’s a reason why they can’t just use `take 2` instead. 8 | 2) Group breaking changes as much as possible 9 | 3) Ensure that docs for all new functions have _examples_ of usage and output. For bonus points, make them doc-tests 10 | 4) Naming is a big part of making *-extra good. If someone wants to make a new function, check other languages to see what they call that function. For example, `groupWhile` means something different to Haskell devs as it does for JS devs 11 | 5) There is never any rush to merge any PRs in a *-extra package. Take your time, and ask for feedback from other users on how useful they might think a function is 12 | 6) Avoid adding new types. There might be a justification for adding a new type, but it would have to be a really really good one. If a function doesn’t work with the data type in the name, then it doesn’t belong in that package 13 | 7) Try to keep as much in the same module. People will expect all the list-extra functions to be in `List.Extra`, not `List.Extra.Banana` 14 | -------------------------------------------------------------------------------- /maintainers.md: -------------------------------------------------------------------------------- 1 | This file contains info on elm-community packages and who the current maintainer for each package. If you wish to become a maintainer for a package, make a PR adding yourself. 2 | 3 | 4 | ## Repo breakdown (in alphabetic order) 5 | | Repo | Description | Maintainer github | Maintainer email | 6 | |------|-------|----------|-------| 7 | | [array-extra](http://github.com/elm-community/array-extra) | Convenience functions for working with Array | lue-bird, jonboiser | lue.the.bird@gmail.com, jonboiser@outlook.com | 8 | | [basics-extra](http://github.com/elm-community/basics-extra) | Additional basic functions | pzp1997 | pzpaul2002@yahoo.com | 9 | | [builtwithelm](http://github.com/elm-community/builtwithelm) | A list of projects and apps built with Elm | prikhi | pavan.rikhi@gmail.com | 10 | | [dict-extra](http://github.com/elm-community/dict-extra) | A library with extra functions for the dictionary type in elm core | | | 11 | | [easing-functions](https://github.com/elm-community/easing-functions) | Easing (animation and timing) library for Elm | Dandandan | danielheres@gmail.com | 12 | | [elm-combine](http://github.com/elm-community/elm-combine/) | A parser combinator library. | stil4m | mstijlaart@gmail.com | 13 | | [elm-faq](http://github.com/elm-community/elm-faq) | FAQ about the Elm language | fredcy | fredcy@gmail.com | 14 | | [elm-webpack-loader](https://github.com/elm-community/elm-webpack-loader) | Webpack loader for Elm | heyakyra | hello@kyra.run | 15 | | [elm-webpack-starter](https://github.com/elm-community/elm-webpack-starter) | Boilerplate for developing Elm apps on Webpack | | | 16 | | [graph](http://github.com/elm-community/graph) | Functional Graph Library in Elm | sgraf812 | sgraf1337@gmail.com | 17 | | [html-extra](http://github.com/elm-community/html-extra) | Additional functions for working with Html | prikhi | pavan.rikhi@gmail.com | 18 | | [intdict](http://github.com/elm-community/intdict) | Optimized dictionary specialization for Integers. Mirrors the dictionary API. | sgraf812 | sgraf1337@gmail.com | 19 | | [json-extra](http://github.com/elm-community/json-extra) | Convenience functions for working with Json | zwilias | mail@ilias.xyz | 20 | | [list-extra](http://github.com/elm-community/list-extra) | Convenience functions for working with List | chadtech | chadtech0@gmail.com | 21 | | [list-split](http://github.com/elm-community/list-split) | Split lists into chunks | jonboiser | jonboiser@outlook.com | 22 | | [maybe-extra](http://github.com/elm-community/maybe-extra) | Convenience functions for working with Maybe | skyqrose | btgtcmxh@sky.skyqrose.com | 23 | | [random-extra](http://github.com/elm-community/random-extra) | Extra functions for Random | | | 24 | | [result-extra](http://github.com/elm-community/result-extra) | Convenience functions for working with Result | prikhi | pavan.rikhi@gmail.com | 25 | | [string-extra](http://github.com/elm-community/string-extra) | String helper functions for Elm | lorenzo & jaapz | jose.zap@gmail.com & jaapz.b@gmail.com | 26 | | [undo-redo](http://github.com/elm-community/undo-redo) | Easy undo in Elm | rohanorton | rohan.orton@gmail.com | 27 | | [typed-svg](http://github.com/elm-community/typed-svg) | Type-safe API for SVG. | rupertlssmith | typedsvg@thesett.com | 28 | 29 | See [this link](https://github.com/orgs/elm-community/repositories?type=archived) for a complete list of archived and deprecated packages that exist under the `elm-community` name. 30 | --------------------------------------------------------------------------------