diff --git a/developer/contributing.rst b/developer/contributing.rst index 57f81bc0..4cf597df 100644 --- a/developer/contributing.rst +++ b/developer/contributing.rst @@ -39,8 +39,8 @@ Check out these two kanban boards: and reviewed by more seasoned contributors. If there's anything you don't understand regarding the board or a specific -github issue, don't hesitate to ask questions in our `general chat -`_. +github issue, don't hesitate to ask questions in our `dev channel +`_. **You don't need to wait for the issue to be assigned to you.** Just check if there is anyone else actively working on it (e.g.: an open pull request @@ -109,12 +109,18 @@ Create a new branch for your patch, use a self-descriptive name, e.g.: .. _openwisp_commit_message_style_guidelines: -2. Commit message style guidelines -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2. Commit message conventions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Please follow our commit message style conventions**. +.. warning:: -If the issue is present on Github, use following commit style: + The commit message conventions described in this section are enforced + by automated checks in the CI builds and can be easily followed by + using the ``openwisp-commit`` tool described in :ref:`Commit message + checks `. + +When working on issues picked from the boards mentioned in the beginning +of this document, please use the following commit message conventions: .. code-block:: @@ -136,7 +142,7 @@ Here's a real world commit message example from `one of our modules Closes #213 -Moreover, keep in mind the following guidelines: +Moreover, keep the following guidelines in mind: - commits should be descriptive in nature, the message should explain the nature of the change @@ -147,11 +153,10 @@ Moreover, keep in mind the following guidelines: - after pushing your branch code, make a pull-request of that corresponding change of yours which should contain a descriptive message and mention the issue number as suggested in the example above -- make sure to send one pull request for each feature. Whenever changes - are requested during reviews, please send new commits (do not amend - previous commits), if multiple commits are present in a single pull - request, they will be squashed in a single commit by the maintainers - before merging +- make sure to send one pull request for each change. Whenever changes are + requested during reviews, please send new commits (do not amend previous + commits), if multiple commits are present in a single pull request, they + will be squashed in a single commit by the maintainers before merging - in case of big features in which multiple related features/changes needs to be implemented, multiple commits (one commit per feature) in a single PR are acceptable. @@ -171,7 +176,7 @@ now on we will shorten it often to just *PR*): our required tests and style checks - if the tests fail for some reason, try to fix them and if you get stuck seek our help on `our communication channels - `_ + `_ - if the tests pass, maintainers will review the PR and may ask you to improve details or changes, please be patient: creating a good quality open source project takes a bit of sweat and effort; ensure to follow up