3Thanks helping with the development of Elm! This document describes the basic
4standards for opening pull requests and making the review process as smooth as
9You need to sign the [contributor agreement](ContributorAgreement.pdf)
10and send it to <info@elm-lang.org> before opening your pull request.
14 * Haskell — conform to [these guidelines][haskell]
15 * JavaScript — use [Google's JS style guide][js]
17[haskell]: https://gist.github.com/evancz/0a1f3717c92fe71702be
18[js]: https://google.github.io/styleguide/javascriptguide.xml
22 * [The master branch][master] is the home of the next release of the compiler
23 so new features and improvements get merged there. Most pull requests
24 should target this branch!
26 * [The stable branch][stable] is for tagging releases and critical bug fixes.
27 This branch is handy for folks who want to build the most recent public
30[master]: http://github.com/elm-lang/elm/tree/master
31[stable]: http://github.com/elm-lang/elm/tree/stable
33If you are working on a fairly large feature, we will probably want to merge it
34in as its own branch and do some testing before bringing it into the master
35branch. This way we can keep releases of the master branch independent of new
38Note that the master branch of the compiler should always be in sync with the
39master branch of the [website][], and the stable branch of the compiler should
40always be in sync with the stable branch of the [website][]. Make sure that
41your changes maintain this compatibility.
43[website]: https://github.com/elm-lang/elm-lang.org
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list