on master help sign in
Merge pull request #657 from yesodweb/githubTemplates

Add Github issue and PR templates, plus contributing guidelines

commitbeeeb9deff9ab3a547f079320c9e06941d043091 authorMichael Snoyman <michael@snoyman.com> dateThu 16 Nov 2017, 09:17 (9 years ago) parent1b1ac47d61b94d
3 files changed+136
.github/ISSUE_TEMPLATE.md+28 .github/PULL_REQUEST_TEMPLATE.md+14 CONTRIBUTING.md+94
.github/ISSUE_TEMPLATE.mdnew file+28
@@ -0,0 +1,28 @@
1+<!---
2+
3+### Bug Reports
4+
5+Reporting a bug? If relevant, we recommend including:
6+
7+* Your OS name and version
8+* The versions of tools you're using (e.g. `stack`, `ghc`).
9+* The versions of dependencies you're using
10+
11+For your convenience, we recommend pasting this script into bash and uploading the output [as a gist](https://gist.github.com/).
12+
13+```
14+command -v sw_vers && sw_vers # OS X only
15+command -v uname && uname -a # Kernel version
16+command -v stack && stack --version
17+command -v stack && stack ghc -- --version
18+command -v stack && stack list-dependencies
19+```
20+
21+* Also, is there anything custom or unusual about your setup? i.e. new or prerelease versions of GHC, Stack, etc.
22+
23+* Finally, if possible, please reproduce the error in a small script, or if necessary create a new Github repo with the smallest possible reproducing case. [Stack's scripting support](https://docs.haskellstack.org/en/stable/GUIDE/#script-interpreter) might be useful for creating your reproduction example.
24+
25+### Support
26+
27+Please direct support questions to [Stack Overflow](https://stackoverflow.com/questions/tagged/yesod+haskell) or the [Yesod Google Group](https://groups.google.com/forum/#!forum/yesodweb). If you don't get a response there, or you suspect there may be a bug in Wai causing your problem, you're welcome to ask here.
28+-->
.github/PULL_REQUEST_TEMPLATE.mdnew file+14
@@ -0,0 +1,14 @@
1+Before submitting your PR, check that you've:
2+
3+- [ ] Bumped the version number
4+- [ ] Documented new APIs with [Haddock markup](https://www.haskell.org/haddock/doc/html/index.html)
5+- [ ] Added [`@since` declarations](http://haskell-haddock.readthedocs.io/en/latest/markup.html#since) to the Haddock
6+
7+After submitting your PR:
8+
9+- [ ] Update the Changelog.md file with a link to your PR
10+- [ ] Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)
11+
12+<!---Thanks so much for contributing! :)
13+
14+_If these checkboxes don't apply to your PR, you can delete them_-->
CONTRIBUTING.mdnew file+94
@@ -0,0 +1,94 @@
1+# Contributing
2+
3+Thanks for your interest in contributing to Wai! This file has some tips for developing Wai and getting a pull request accepted.
4+
5+## Development
6+
7+Wai is a mega-repo that contains many Haskell packages, each in a different directory. All the subprojects can be developed with Stack, using `stack <command> <subproject>`, e.g.
8+
9+* `stack build mime-types`
10+* `stack test auto-update`
11+* `stack haddock warp`
12+
13+If you'd like to test your changes in a full-fledged Wai app, you can use Stack to build against it, e.g.:
14+
15+```
16+packages:
17+- '/path/to/this/repo/wai'
18+```
19+
20+## Coding Guidelines
21+
22+### Safety
23+
24+Avoid partial functions. Even if you know the partial function is safe in your instance, partial functions require more reasoning from the programmer and are not resilient to refactoring. For the rare cases where a partial function is appropriate, a custom `error` should be used.
25+
26+### Style
27+
28+Keep coding style consistent with the rest of the file, but don't worry about style too much otherwise. PRs changing code style are viewed skeptically.
29+
30+### Dependencies
31+
32+Avoid adding unnecessary dependencies. If a dependency provides only a minor convenience for your implementation, it's probably better to skip it.
33+
34+If you do add a new dependency, try to support a wide range of versions of it.
35+
36+### Backwards Compatibility
37+
38+Backwards incompatible changes are viewed skeptically—best to ask in an issue to see if a particular backwards incompatible change would be approved. If possible keep backwards compatibility by adding new APIs and deprecating old ones.
39+
40+Keep backwards compatibility with old versions of dependencies when possible.
41+
42+## PR Guidelines
43+
44+### PR Scope
45+
46+As much as possible, keep separate changes in separate PRs.
47+
48+### Testing
49+
50+Tests are recommended, but not required.
51+
52+### Documentation
53+
54+All public APIs must be documented. Documenting private functions is optional, but may be nice depending on their complexity. Example documentation:
55+
56+```
57+-- | Generate an action which will either read from an automatically
58+-- updated value, or run the update action in the current thread.
59+--
60+-- ==== __Examples__
61+--
62+-- > getTime <- mkAutoUpdate defaultUpdateSettings
63+--
64+-- @since 0.1.0
65+mkAutoUpdate :: UpdateSettings a -> IO (IO a)
66+```
67+
68+Examples are recommended, but not required, in documentation. Marking new APIs with `@since <version number>` is required.
69+
70+### Versioning
71+
72+Wai packages roughly follow the Haskell Package Versioning Policy style of A.B.C.[D] (MAJOR.MAJOR.MINOR.[PATCH])
73+
74+* A - Used for massive changes in the library. (Example: 1.2.3.4 becomes 2.0.0)
75+* B - Used for smaller breaking changes, like removing, renaming, or changing behavior of existing public API. (Example: 1.2.3.4 becomes 1.3.0)
76+* C - Used for new public APIs (Example: 1.2.3.4 becomes 1.2.4)
77+* D - Used for bug fixes (Example: 1.2.3.4 becomes 1.2.3.5).
78+ * D is optional in the version number, so 2.0.0 is a valid version.
79+
80+Documentation changes don't require a new version.
81+
82+If you feel there is ambiguity to a change (e.g. fixing a bug in a function, when people may be relying on the old broken behavior), you can ask in an issue or pull request.
83+
84+Unlike in the Package Versioning Policy, deprecations are not counted as MAJOR changes.
85+
86+In some cases, dropping compatibility with a major version of a dependency (e.g. changing from transformers >= 0.3 to transformers >= 0.4), is considered a breaking change.
87+
88+### Changelog
89+
90+After you submit a PR, update the subproject's Changelog.md file with the new version number and a link to your PR. If your PR does not need to bump the version number, include the change in an "Unreleased" section at the top.
91+
92+### Releases
93+
94+Releases should be done as soon as possible after a pull request is merged—don't be shy about reminding us to make a release if we forget.