Thanks helping with the development of Elm! This document describes the basic standards for opening pull requests and making the review process as smooth as possible.
- Always make pull requests minimal. If it can be split up, it should be split up.
- Use style consistent with the file you are modifying.
- Use descriptive titles for PRs
- Provide all the necessary context for evaluation in the PR. If there are relevant issues or examples or discussions, add them. If things can be summarized, summarize them. The easiest PRs are ones that already address the reviewers questions and concerns.
If you want to fix docs, just open a PR. This is super helpful!
If you find an issue or see one you want to work on, go for it!
The best strategy is often to dive in. Asking for directions usually does not work. If someone knew the specifics and knew how how to fix it, it is likely they would have already sent the PR themselves!
Also, be sure you are testing.
We are fairly conservative about adding new functions to core libraries.
If you want to augment the List or Array library, we recommend creating
small packages called list-extras or array-extras that have all the
features you want.
Long term, we will set up a process to review *-extras packages to move
stuff into core. By going through packages, it will be much easier to assess
whether a function is pleasant and useful in practice before committing to it
in the core libraries.