Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider renaming repo to a more literal name #7

Closed
duncanmalashock opened this issue Sep 15, 2018 · 1 comment
Closed

Consider renaming repo to a more literal name #7

duncanmalashock opened this issue Sep 15, 2018 · 1 comment

Comments

@duncanmalashock
Copy link
Member

From https://discourse.elm-lang.org/t/literal-names-policy-i-e-how-to-name-packages/242:

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
Copy link
Member Author

Resolved by #13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant