diff options
-rw-r--r-- | COMMITTERS.md | 90 | ||||
-rw-r--r-- | CONTRIBUTING.md | 16 |
2 files changed, 103 insertions, 3 deletions
diff --git a/COMMITTERS.md b/COMMITTERS.md new file mode 100644 index 000000000..df5fee94d --- /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.
+* Is 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..a07423d5b 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/`, to `develop` or `master` branch. * 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 fix 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 to `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) + |