When I create a package, I ask “What is this package for?” and the answer to that question is the name of the package. If I do not know what it is for, something has gone very wrong if I think it’s worth having other people review and possibly use this code!
This means we get elm-lang/html, evancz/elm-parser, rtfeldman/elm-css, etc. You can immediately know what it’s for. No cute branding to sift through. The only real distinguishing feature of the name is the author. This is extremely important information! You are implicitly collaborating with the author, and it is important to trust their quality, stability, communication, etc.
The Elm community seems to be firmly against "branding" packages in the JS style, and many popular packages have renamed to adhere to this policy (e.g. "style-elements" became "elm-ui", "graphqelm" became "elm-graphql"). Based on this thread, I think this package will face unnecessary struggle to be taken seriously if it isn't renamed.
I would suggest the more literal name "elm-music-theory", but if there is another name that describes this package more literally still, so much the better.
duncanmalashock
commented
6 years ago
From https://discourse.elm-lang.org/t/literal-names-policy-i-e-how-to-name-packages/242:
The Elm community seems to be firmly against "branding" packages in the JS style, and many popular packages have renamed to adhere to this policy (e.g. "style-elements" became "elm-ui", "graphqelm" became "elm-graphql"). Based on this thread, I think this package will face unnecessary struggle to be taken seriously if it isn't renamed.
I would suggest the more literal name "elm-music-theory", but if there is another name that describes this package more literally still, so much the better.