@@ -0,0 +1,79 @@
1+# Contributing Guidelines
2+
3+Contributions are very welcome! To hack on the github version, clone the
4+repository. You can use `cabal`:
5+
6+```shell
7+./scripts/start-sandbox.sh # Initialize the sandbox and add-source the packages
8+./scripts/test-all.sh # Run all the tests
9+```
10+
11+`stack`:
12+
13+```shell
14+stack build # Install and build packages
15+stack test # Run all the tests
16+```
17+
18+Or `nix`:
19+```shell
20+./scripts/generate-nix-files.sh # Get up-to-date shell.nix files
21+```
22+
23+
24+## General
25+
26+Some things we like:
27+
28+- Explicit imports
29+- Upper and lower bounds for packages
30+- Few dependencies
31+- -Werror-compatible (for both 7.8 and 7.10)
32+
33+Though we aren't sticklers for style, the `.stylish-haskell.yaml` and `HLint.hs`
34+files in the repository provide a good baseline for consistency.
35+
36+Please include a description of the changes in your PR in the `CHANGELOG.md` of
37+the packages you've changed. And of course, write tests!
38+
39+## PR process
40+
41+We try to give timely reviews to PRs that pass CI. If CI for your PR fails, we
42+may close the PR if it has been open for too long (though you should feel free
43+to reopen when the issues have been fixed).
44+
45+We require two +1 from the maintainers of the repo. If you feel like there has
46+not been a timely response to a PR, you can ping the Maintainers group (with
47+`@Maintainers`).
48+
49+## New combinators
50+
51+We encourage people to experiment with new combinators and instances - it is
52+one of the most powerful ways of using `servant`, and a wonderful way of
53+getting to know it better. If you do write a new combinator, we would love to
54+know about it! Either hop on #servant on freenode and let us know, or open an
55+issue with the `news` tag (which we will close when we read it).
56+
57+As for adding them to the main repo: maintaining combinators can be expensive,
58+since official combinators must have instances for all classes (and new classes
59+come along fairly frequently). We therefore have to be quite selective about
60+those that we accept. If you're considering writing a new combinator, open an
61+issue to discuss it first! (You could release your combinator as a separate
62+package, of course.)
63+
64+
65+## New classes
66+
67+The main benefit of having a new class and package in the main servant repo is
68+that we get to see via CI whether changes to other packages break the build.
69+Open an issue to discuss whether a package should be added to the main repo. If
70+we decide that it can, you can still keep maintainership over it.
71+
72+Whether or not you want your package to be in the repo, create an issue with
73+the `news` label if you make a new package so we can know about it!
74+
75+## Release policy
76+
77+We are currently moving to a more aggresive release policy, so that you can get
78+what you contribute from Hackage fairly soon. However, note that prior to major
79+releases it may take some time in between releases.