Update CONTRIBUTING.md

Author: GrazianoCapelli

CONTRIBUTING.md

@@ -27,9 +27,9 @@ Basing on https://nvie.com/posts/a-successful-git-branching-model/ (you can see
 
 - **master** = The long life branch that contains the releases of the application. Usually we merge the release into master when it has been released and we keep updated README, Frequently Asked Question, Fastlane structure, and other documentation for the release we published. We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
 - **develop** = Another long life branch that goes in parallel with master. The develop is the branch where the developers work. Usually a developer, when implements a feature, creates a new branch starting from the develop branch. When ready, the feature will be merged back into develop. We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.
-- **feature branches** = Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment). We are used to call them "issue-XXX" when associated with an issue.
+- **feature branches** = Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. Feature branches usually start from the latest commit of the develop branch and are eventually merged back into develop. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).<br>The feature branches are usually associated with an open issue (used for ideas, proposal, discussion, mockups, and to post the status of the implementation) and are named "issue-XXX", where XXX is the associated issue.
 
-We are used to include the number of the issue (#number) into the description of the commit (when applicable), in order to put a note of the new progress automatically into the issue.
+We are used to include the number of the issue (#number) into the description of the commit (when applicable), in order to put a note of the new progress automatically into the issue. A good comment is for example `#172 - Fix crash on Android 4 loading the Drawable`.
 
 Here a schema of the Git model we are basing on, that shows master, develop, and feature branches: