@@ -9,26 +9,53 @@ we will appreciate if you provide as much detail as possible to reproduce or
9understand the problem, but nevertheless you are encouraged to open an issue
9understand the problem, but nevertheless you are encouraged to open an issue
10for any problem that you may encounter.
10for any problem that you may encounter.
12−## Developer documentation
14−Build haddock with the `--show-all` option to see the documentation for all
15−modules including the ones not exposed to users of the library.
17−`stack haddock --haddock-arguments "--show-all" --no-haddock-deps`.
19## Pull Requests (PR)
12## Pull Requests (PR)
21Please feel free to [send a pull
14Please feel free to [send a pull
22−request (PR)](https://github.com/composewell/streamly/pulls) whether it is a single
15+request (PR)](https://github.com/composewell/streamly/pulls) whether it is a
23−letter typo fix in documentation or a more complex change. If the feature makes
16+single letter typo fix or a complex change. We will accept any PR that makes a
17+net positive change to the package. We encourage you to provide a complete,
18+consistent change with test, documentation and benchmarks. You can contact the
19+[maintainers](https://gitter.im/composewell/streamly) for any help or
20+collaboration needed in that regard. However, if due to lack of time you are
21+not able to complete the PR, you are still welcome to submit it, maintainers
22+will try their best to actively contribute and pick up your change as long as
23+the change is approved.
25+## Pull Request (PR) Checklist
27+Here is a quick checklist for a PR, for details please see the next section:
29+* PR contains one logical changeset
30+* Each commit in the PR consists of a logical change
31+* Commits are rebased/squashed/fixup/reordered as needed
32+* Stylistic changes to irrelevant parts of the code are separated in
34+* Code is formatted as per the style of the file or that of other files
35+* Compiler warnings are fixed
36+* Reasonable hlint suggestions are accepted
37+* Tests are added to cover the changed parts
38+* All [tests](test) pass
39+* [Performance benchmarks](benchmark) are added, where applicable
40+* No significant regressions are reported by [performance benchmarks](benchmark/README.md)
41+* Haddock documentation is added to user visible APIs and data types
42+* Tutorial module, [README](README.md), and [guides](docs) are updated if
44+* [Changelog](Changelog.md) is updated if needed
46+## Contributing A Change
24−significant changes to design, we encourage you to open an issue as early as
48+If the feature makes significant changes to design, we encourage you to open an
25−possible so that you do not have to redo much work because of changes in design
49+issue as early as possible so that you do not have to redo much work because of
26−decisions. However, if you are confident, you can still go ahead and take that
50+changes in design decisions. However, if you are confident, you can still go
27−risk.
51+ahead and take that risk as the maintainers are supposed to be reasonable
29### Picking Issues to Work on
54### Picking Issues to Work on
31−Beginners are encouraged to pick up issues that are marked `help wanted`.
56+Beginners are encouraged to pick up issues that are marked `help wanted`. It is
57+a good idea to update the issue expressing your intent so that others do not
58+duplicate the effort and people with a background on the issue can help.
33### Changeset in a PR
60### Changeset in a PR
@@ -60,13 +87,16 @@ BRANCH.
61### Testing
88### Testing
63−It is a good idea to include tests for the changes where applicable.
90+It is a good idea to include tests for the changes where applicable. See the
91+existing tests [here](test).
65### Documentation
93### Documentation
67For user visible APIs, it is a good idea to provide haddock documentation that
95For user visible APIs, it is a good idea to provide haddock documentation that
68is easily understood by the end programmer and does not sound highfalutin,
96is easily understood by the end programmer and does not sound highfalutin,
69−and preferably with examples.
97+and preferably with examples. If your change affects the tutorial or needs to
98+be mentioned in the tutorial then please update the tutorial. Check if the
99+additional [guides](docs) are affected or need to updated.
71### Performance Benchmarks
101### Performance Benchmarks
@@ -75,8 +105,8 @@ any of the existing performance benchmarks. If you introduced something new
75then you may want to add benchmarks to check if it performs as well as expected
105then you may want to add benchmarks to check if it performs as well as expected
76by the programmers to deem it usable.
106by the programmers to deem it usable.
78−See the README file in the `benchmark` directory for more details on how to run
108+See the [README](benchmark/README) file in the `benchmark` directory for more
79−the benchmarks.
109+details on how to run the benchmarks.
81### Changelog
111### Changelog
@@ -99,6 +129,13 @@ of the library please indicate that in the `Changelog` as `Breaking Changes`
99and also write short notes regarding what the programmers need to do to adapt
129and also write short notes regarding what the programmers need to do to adapt
100their existing code to the new change.
130their existing code to the new change.
132+## Developer documentation
134+Build haddock with the `--show-all` option to see the documentation for all
135+modules including the ones not exposed to users of the library.
137+`stack haddock --haddock-arguments "--show-all" --no-haddock-deps`.