Add explanations on how to contribute
(François Bobot) On GitHub, since the file is named CONTRIBUTING.md, a link is added on the page for creating merge request to it. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16467 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02master
parent
3397e7ff16
commit
76196708c8
|
@ -0,0 +1,45 @@
|
||||||
|
# How to contribute
|
||||||
|
|
||||||
|
:+1::tada: First off, thank you for taking time to contribute! :tada::+1:
|
||||||
|
|
||||||
|
The following is a set of guidelines for contributing to OCaml. These
|
||||||
|
are just guidelines, not rules, use your best judgment and feel free
|
||||||
|
to propose changes to this document in a pull request.
|
||||||
|
|
||||||
|
## Coding Guidelines
|
||||||
|
|
||||||
|
* indentation: particular ocp-indent configuration?
|
||||||
|
* first match pattern with/without `|`?
|
||||||
|
* CamelCase? snake_case?
|
||||||
|
|
||||||
|
## Submitting a Pull Request
|
||||||
|
|
||||||
|
|
||||||
|
* Add new tests.
|
||||||
|
* Merge request for bug-fix must contain tests which fail before
|
||||||
|
application of the fix and not after. The best way, if possible, is
|
||||||
|
to add the test in one commit before the fix with an output
|
||||||
|
reference file which shows the error. Then in another commit add
|
||||||
|
the fix and update the reference file. Doing so help to see what
|
||||||
|
is the effect of the fix.
|
||||||
|
* Merge request adding a new feature must add tests for normal and
|
||||||
|
wrong uses of the feature.
|
||||||
|
|
||||||
|
* You should run all the tests before creating the merge request or
|
||||||
|
pushing new commits (even if travis will also do it for you): `make
|
||||||
|
tests`.
|
||||||
|
|
||||||
|
* The description of the merge request must contain a precise
|
||||||
|
explanation of the new feature and a proposition to modify the
|
||||||
|
ocaml manual.
|
||||||
|
|
||||||
|
* Try to split commit into logical units. For example:
|
||||||
|
* If a modification requires refactoring of existing code, the
|
||||||
|
refactoring and the modification should be done in two different
|
||||||
|
commits.
|
||||||
|
* Optimizations should go in specific commits, and so keep simple
|
||||||
|
a previous commit that adds a functionality.
|
||||||
|
|
||||||
|
* Contributor License Agreement?
|
||||||
|
|
||||||
|
* Changelog?
|
Loading…
Reference in New Issue