Add COMMITTERS.md file & Update CONTRIBUTING.md

Related:
       APPLINK-20934

2 files changed, 103 insertions, 3 deletions

diff --git a/COMMITTERS.md b/COMMITTERS.md
new file mode 100644
index 000000000..f4debf609
--- /dev/null
+++ b/COMMITTERS.md
@@ -0,0 +1,90 @@
+#Committing changes to SDL

+

+We would like to make it easier for community members to contribute to SDL

+using pull requests. This makes the process of contributing a little easier for the contributor since they don't

+need to concern themselves with the question, "What branch do I base my changes

+on?"  This is already called out in the CONTRIBUTING.md.

+

+##Terminology

+Many of these terms have more than one meaning. For the purposes of this

+document, the following terms refer to specific things.

+

+**contributor** - A person who makes a change to SDL and submits a change

+set in the form of a pull request.

+

+**reviewer** - A person responsible for reviewing a pull request.

+

+**master branch** - [The base branch](https://github.com/smartdevicelink/sdl_core/tree/master).

+

+**develop branch** - [The branch](https://github.com/LuxoftSDL/sdl_core/tree/develop) where bug fixes against the latest release or release candidate are merged.

+

+##Pull request checklist

+* Add Unit tests.

+* All tests pass (see Run all tests section).

+* Check component design

+* Check amount of required memory, memory leaks.

+* Assertion must be used in the right way.

+* Are there cyclic dependencies?

+* Level of abstraction adequate?

+* Are there any platform gotchas? (Does a change make an assumption about

+   platform specific behavior that is incompatible with other platforms?  e.g.

+   Windows paths vs. POSIX paths).

+* Thread safe code.

+* No deadlocks.

+* Doxygen API documentation available?

+* Do you have thread specific comment provided? (if another thread uses added method/classes, 

+   there must be comment which explains: When method will be called by thread? Which thread calls the method? e.g.)

+* Do you have specific realization code comments?

+* Add log messages.

+* There are no Google code style errors. (You can download Google [cppint.py](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py))

+* Check branch naming.

+* Check correct commit messages in commits (see Pull request message section).

+* Check correct pull request target (`master` or `develop`)

+* Check correct pull request message

+* Add reviewers

+

+##Run all tests

+* Run in root build directory `make test`

+

+##Branch naming

+Branch name should be:

+* `hotfix/<task name>` or

+* `feature/<task name>` or

+* `fix/<task name>`

+

+##Pull request message

+* Describe the reason why you created pull request and what changes there are.

+* Add related Jira ticket as link.

+   ( EXAMPLE:

+   `Related: [APPLINK-xxxxx](put direct link here)`)

+* If there was an old pull request, add link. ( EXAMPLE: `Old pull request is [here](put direct link here)`)

+

+##Adding reviewers:

+* Add one domain expert

+* Add your mentor (for junior developers only)

+* Add all junior developers (for junior developers only)

+

+`Note`: Everyone from SDL team developers can review any pull request (“reviewed” comment is not required)

+

+##Review process

+* Reviewers can leave comments to code only in `commits` tab.

+* Contributor must answer each comment (Contributor should specify addressee in comment).

+* In case contributor is disagree with reviewer, contributor writes his opinion

+* In case contributor is agree with reviewer, contributor leaves link to new commit with changes.

+* When reviewer is agree with all changes in pull request, he must leave `Reviewed` comment.

+

+##Successfully passed review:

+* Contributor answered to all comments

+* Contributor fixed all mistakes

+* All reviewers left `Reviewed` comment

+

+##Merging

+* Successfully passed review.

+* Rebase in case of existing conflicts.

+* Contributor can squash commits in case of adding same code in different commits.

+* Contact @AGaliuzov or @anosach-luxoft to merge pull request.

+

+##Additional sources

+* [Google cppint.py](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py)

+* [Git commit best practices](http://chris.beams.io/posts/git-commit/)

+* [GitHub Working with formatting](https://help.github.com/articles/working-with-advanced-formatting/)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index db408b7e9..754ea407f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -12,14 +12,24 @@ We use <a href="http://nvie.com/posts/a-successful-git-branching-model/">Gitflow
 
 ### Pull Requests
 * Please follow the repository's for all code and documentation.
+* All pull requests should be sent to `smartdevicelink/sdl_core/`, in `develop` or `master` branches.
 * All feature branches should be based on `develop` and have the format `feature/branch_name`.
-* Minor bug fixes, that is bug fixes that do not change, add, or remove any public API, should be based on `master` and have the format `hotfix/branch_name`.
+* All hotfix branches should be based on `develop` and have the format `fix/branch_name`.
+* All new functionality requests should be provided only for `develop` branch.
+* In case defect should be fixed in short time (after release), send pull request on `master` and have the format `hotfix/branch_name`. 
+* In case defect exists in `develop` and `master` branches, send pull request to `develop` only. Do not send the same pull request to the `master` branch. 
 * All pull requests should implement a single feature or fix a single bug. Pull Requests that involve multiple changes (it is our discretion what precisely this means) will be rejected with a reason.
-* All commits should separated into logical units, i.e. unrelated changes should be in different commits within a pull request.
+* All commits should be separated into logical units, i.e. unrelated changes should be in different commits within a pull request.
 * Work in progress pull requests should have "[WIP]" in front of the Pull Request title. When you believe the pull request is ready to merge, remove this tag and @mention the appropriate SDL team to schedule a review.
 * All new code *must* include unit tests. Bug fixes should have a test that fails previously and now passes. All new features should be covered. If your code does not have tests, or regresses old tests, it will be rejected.
-* A great example of a <a href="https://github.com/smartdevicelink/SmartDeviceLink-iOS/pull/45" "_target>pull request can be found here</a>.
+* A great example of a [pull request can be found here](https://github.com/smartdevicelink/SmartDeviceLink-iOS/pull/45).
 
 ### Contributor's License Agreement (CLA)
 In order to accept Pull Requests from contributors, you must first sign [the Contributor's License Agreement](https://docs.google.com/forms/d/1VNR8EUd5b46cQ7uNbCq1fJmnu0askNpUp5dudLKRGpU/viewform). If you need to make a change to information that you entered, [please contact us](mailto:justin@livio.io).
 
+## Additional Resources
+* [General GitHub documentation](https://help.github.com/)
+* [GitHub pull request documentation](https://help.github.com/send-pull-requests/)
+* [Contributor's License Agreement](https://docs.google.com/forms/d/1VNR8EUd5b46cQ7uNbCq1fJmnu0askNpUp5dudLKRGpU/viewform)
+* [Committers.md](https://github.com/LuxoftSDL/sdl_core/blob/feature/Add_Committers_file/COMMITTERS.md)
+