streamly/CONTRIBUTING.md

100 lines
4.0 KiB
Markdown
Raw Normal View History

2018-03-11 16:10:10 +03:00
# Contributors' Guide
## Bug Reports
Please feel free to [open an
issue](https://github.com/composewell/streamly/issues) for any questions,
suggestions, issues or bugs in the library. In case you are reporting a bug
we will appreciate if you provide as much detail as possible to reproduce or
understand the problem, but nevertheless you are encouraged to open an issue
for any problem that you may encounter.
## Pull Requests (PR)
Please feel free to [send a pull
request (PR)](https://github.com/composewell/streamly/pulls) whether it is a single
letter typo fix in documentation or a more complex change. If the feature makes
significant changes to design, we encourage you to open an issue as early as
possible so that you do not have to redo much work because of changes in design
decisions. However, if you are confident, you can still go ahead and take that
risk.
### Picking Issues to Work on
Beginners are encouraged to pick up issues that are marked `help wanted`.
### Changeset in a PR
* Please make sure that a single PR contains a single logical changeset. That
helps the reviewers in quickly understanding and reviewing the change.
* You are encouraged to group a logically related set of changes into a single
commit. When the overall changeset is largish you can divide it into
multiple smaller commits, with each commit having a logically grouped
changeset and the title summarizing the logical grouping. Always keep in
mind a logical division helps reviewers understand and review your code
quickly, easier history tracking and when required clean reversal changes.
* If your commits reflect how you fixed intermediate problems during testing
or made random changes at different times you may have to squash your changes
(`git rebase -i`) into a single commit or logically related set of commits.
* Please resist the temptation to make style related changes to surrounding
code unless you are changing that code anyway . Make sure that your
IDE/Editor is not automatically making sweeping style changes to all the
files you are editing. That makes separating the signal from the noise
very difficult and makes everything harder. If you would like to make style
related changes then please send a separate PR with just those changes and no
other functionality changes.
### Resolving Conflicts
If during the course of development or before you send the PR you find that
your changes are conflicting with the master branch then use `git rebase
master` to rebase your changes on top of master. DO NOT MERGE MASTER INTO YOUR
BRANCH.
### Testing
It is a good idea to include tests for the changes where applicable.
### Documentation
For user visible APIs, it is a good idea to provide haddock documentation that
is easily understood by the end programmer and does not sound highfalutin,
and preferably with examples.
### Performance Benchmarks
It is a good idea to run performance benchmarks to see if your change affects
any of the existing performance benchmarks. If you introduced something new
then you may want to add benchmarks to check if it performs as well as expected
by the programmers to deem it usable.
### Changelog
If you make changes that are incompatible with the released versions of the
library please indicate that in the `Changelog` as `Breaking Changes` and what
the programmers need to do to adapt to the new change. Any new user visible
changes must be documented in the `Changelog`.
## Coding Style
As long as possible please try to match the style of the file or the
2018-03-11 17:50:42 +03:00
surrounding code. For haskell coding style guidelines, please [see this style
guide](https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md).
Specifically,
2018-03-11 16:10:10 +03:00
* Please use 4 spaces for indentation.
* Do not let the code go beyond 79 columns
* Use multiline `let` clauses like this:
```
let stop = stp
yield a Nothing = ...
...
```
* Align the contents of the where clause in the same column as the `where`
keyword for saving unnecessary indentation, like this:
```
where
x = ...
```