diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8077813..16de1e5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -162,7 +162,7 @@ $ ./rebar3 ct ``` Most tests are named according to their module name followed by the `_SUITE` -suffi. Providers are made shorter, such that `rebar_prv_new` is tested in +suffix. Providers are made shorter, such that `rebar_prv_new` is tested in `rebar_new_SUITE`. Most tests in the test suite will rely on calling Rebar3 in its API form, @@ -285,7 +285,7 @@ The reviewer may ask you to later squash the commits together to provide a clean commit history before merging in the feature. It's important to write a proper commit title and description. The commit title -should fir around 50 characters; it is the first line of the commit text. The +should be no more than 50 characters; it is the first line of the commit text. The second line of the commit text must be left blank. The third line and beyond is the commit message. You should write a commit message. If you do, wrap all lines at 72 characters. You should explain what the commit does, what @@ -299,7 +299,7 @@ maintainers. When opening a pull request, explain what the patch is doing and if it makes sense, why the proposed implementation was chosen. Try to use well-defined commits (one feature per commit) so that reading -them and testing them is easier for reviewers and while bissecting the code +them and testing them is easier for reviewers and while bisecting the code base for issues. During the review process, you may be asked to correct or edit a few things |