git.iko.soy/obelisk
on release/0.1.0.0 help sign in
obelisk/CONTRIBUTING.md
63 lines 2.9 kB history raw
1# Contribution Guide
3Contributions and issue reports are encouraged and appreciated!
5- [Opening Issues](#opening-issues)
6- [Submitting Changes](#submitting-changes)
7 - [Guidelines for Commit Messages](#guidelines-for-commit-messages)
8 - [Code Quality](#code-quality)
9 - [Documentation](#documentation)
11## Opening Issues
13Before opening an issue, please check whether your issue has already been reported. Assuming it has not:
15* Describe the issue you're encountering or the suggestion you're making
16* Include any relevant steps to reproduce or code samples you can. It's always easier for us to debug if we have something that demonstrates the error.
17* Let us know what version of this project you were using. If you're using a github checkout, provide the git hash.
19## Submitting Changes
21Most pull requests should target the `develop` branch. `master` is the release branch. `develop` is periodically merged into master after a period of testing.
23### Guidelines for Commit Messages
25#### Summary Line
26The summary line of your commit message should summarize the changes being made. Commit messages should be written in the imperative mood and should describe what happens when the commit is applied. If your commit modifies one of the in-tree haskell packages (found in `./lib`), please prefix your commit summary with the name of the package being modified.
28One way to think about it is that your commit message should be able to complete the sentence:
29"When applied, this commit will..."
31#### Body
32For breaking changes, new features, refactors, or other major changes, the body of the commit message should describe the motivation behind the change in greater detail and may include references to the issue tracker. The body shouldn't repeat code/comments from the diff.
34### Code Quality
36#### Warnings
38Your pull request should add no new warnings to the project. It should also generally not disable any warnings.
40#### Build and Test
42Make sure the project builds and that the tests pass! This will generally also be checked by CI before merge, but trying it yourself first means you'll catch problems earlier and your contribution can be merged that much sooner!
44You can run the tests like this:
45```bash
46$(nix-build -A selftest --no-out-link)
47```
49### Documentation
51#### In the code
52We're always striving to improve documentation. Please include [haddock](https://haskell-haddock.readthedocs.io/en/latest/index.html) documentation for any added code, and update the documentation for any code you modify.
54#### In the [Changelog](ChangeLog.md)
55Add an entry to the changelog when your PR:
56* Adds a feature
57* Deprecates something
58* Includes a breaking change
59* Makes any other change that will impact users
61#### In the [Readme](README.md)
62The readme is the first place a lot of people look for information about the repository. Update any parts of the readme that are affected by your PR.