The goals of this project are the following:
- implement a faithful port of the Erlang webmachine project;
- support lwt and async equally well; and
- impose as few dependencies on the user as possible.
The best way to get a pull request accepted is for it to directly serve the goals of the project, while being simple and straightforward for project maintainers to evalute it in terms of functionality and maintainability. In service to the these criteria, pull request and commit messages should clearly describe what they include and why. Generally speaking, follow the guidelines of this blog post when composing commit messages. Pull requests should pass existing tests and include additional tests when appropriate. The code should be clear rather than clever (two-liners over one-liners), and documented when the code can't speak for itself.
If a part of the existing code is not relevant to the topic of your pull request, please refrain from modifying it (see below). If a change or feature will have a large effect on the codebase, bring it up for discussion in an issue. To quote a tweet:
People of github,
- Raise issue
- Discuss, propose solution
- Implement
Sometimes it's ok to skip a step, but pls don't change the order.
Releases will be prepared and performed by maintainers. Please do not include any changes related to release management in your contributions.
Two space indentation. No tabs. No trailing whitespace. If you find any violations in or around code that you need to modify, feel free to fix it. If you find violations in unrelated code, just leave it there.
In the event that a contribution requires changes to the project's dependencies, here's how you should incorporate those changes into the build/release process:
- Modify the
dunefile to reflect changed dependencies; and - Update
opam/opamto reflect the changes made in thedunefile.
Try to include these changes in a separate commit. That's not always possible, so don't sweat it too much if you can't.