@@ -0,0 +1,76 @@
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
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 require two +1 from the maintainers of the repo. If you feel like there has
42+not been a timely response to a PR, you can ping the Maintainers group (with
43+`@Maintainers`).
44+
45+## New combinators
46+
47+We encourage people to experiment with new combinators and instances - it is
48+one of the most powerful ways of using `servant`, and a wonderful way of
49+getting to know it better. If you do write a new combinator, we would love to
50+know about it! Either hop on #servant on freenode and let us know, or open an
51+issue with the `news` tag (which we will close when we read it).
52+
53+As for adding them to the main repo: maintaining combinators can be expensive,
54+since official combinators must have instances for all classes (and new classes
55+come along fairly frequently). We therefore have to be quite selective about
56+those that we accept. If you're considering writing a new combinator, open an
57+issue to discuss it first!
58+
59+
60+## New classes
61+
62+The main benefit of having a new class and package in the main servant repo is
63+that we get to see via CI whether changes to other packages break the build.
64+Open an issue to discuss whether a package should be added to the main repo. If
65+we decide that it can, you can still keep maintainership over it.
66+
67+Whether or not you want your package to be in the repo, create an issue with
68+the `news` label if you make a new package so we can know about it!
69+
70+## Release policy
71+
72+We are currently moving to a more aggresive release policy, so that you can get
73+what you contribute from Hackage fairly soon. However, note that prior to major
74+releases it may take some time in between releases. If you think you're change
75+is small enough that you should be backported to released major versions, say
76+so in the issue or PR.