| 1 |
# How To Contribute |
| 2 |
|
| 3 |
Thanks for reading our contribution guidelines. |
| 4 |
|
| 5 |
The following guidelines for contribution should be followed if you want to submit a pull request. |
| 6 |
|
| 7 |
## How To Prepare |
| 8 |
|
| 9 |
* You need a [](https://github.com/signup/freeGitHub account](https://github.com/signup/free](https://github.com/signup/free). |
| 10 |
* Before reporting a bug or suggesting an improvement, please check the `develop` branch to see if it has already been addressed. |
| 11 |
* Duplicate tickets will be closed without hesitation, so please check through existing tickets first to see if someone else has already discussed it. |
| 12 |
* Submit an [issue ticket] for your issue if there is not one yet. |
| 13 |
* Describe the issue and include steps to reproduce if it's a bug. |
| 14 |
* If the issue is a bug, add any relevant JavaScript or PHP error messages. For PHP error messages, a backtrace is preferred. If you don't know how to get one, please [](https://gist.github.com/jrfnl/5925642follow these instructions](https://gist.github.com/jrfnl/5925642](https://gist.github.com/jrfnl/5925642). |
| 15 |
* Include relevant version numbers. |
| 16 |
* Additional screenshots or videos are often helpful. |
| 17 |
* If you are able and want to fix this, fork the repository on GitHub. |
| 18 |
|
| 19 |
## Make Changes |
| 20 |
|
| 21 |
We use the [](http://nvie.com/posts/a-successful-git-branching-model/git-flow](http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model/) branching model. Before reporting a bug or new feature, please check the `develop` branch to see if it's already been addressed. |
| 22 |
|
| 23 |
* In your forked repository, create a topic branch for your upcoming patch. Usually this is based on the `develop` branch. |
| 24 |
* For enhancements, name the branch according to the feature e.g. `feature/auto-activate`. |
| 25 |
* For un-reported bug fixes, add a `fix-` prefix e.g. `feature/fix-admin-notices`. |
| 26 |
* For code that addresses an existing Issue, add the Issue number as a prefix e.g. `feature/123-auto-activate` or `feature/321-fix-admin-notices`. |
| 27 |
* Please avoid working directly on the `develop` branch. |
| 28 |
* Code should follow the [](https://make.wordpress.org/core/handbook/coding-standards/php/WordPress Coding Standards for PHP](https://make.wordpress.org/core/handbook/coding-standards/php/](https://make.wordpress.org/core/handbook/coding-standards/php/). |
| 29 |
* Use [](https://github.com/squizlabs/PHP_CodeSnifferPHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) with the [](https://github.com/WordPress-Coding-Standards/WordPress-Coding-StandardsWordPress Coding Standards](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards) sniffs to check. Since we use `phpcs.xml`, you should be able to navigate on command line to the root of the repo and just run `phpcs` without any arguments. |
| 30 |
* Make commits of logical units and describe them properly. |
| 31 |
* Check for unnecessary whitespace with `git diff --check` before committing. |
| 32 |
|
| 33 |
## Commit Messages |
| 34 |
We suggest you follow best practices for commit messages: |
| 35 |
|
| 36 |
* Separate subject (first line) from body with a blank line. |
| 37 |
* Limit the subject line to 50 characters. |
| 38 |
* Capitalize the subject line. |
| 39 |
* Do not end the subject line with a period. |
| 40 |
* Use the imperative mood in the subject line. |
| 41 |
* Wrap the body at 72 characters. |
| 42 |
* Use the body to explain _what_ and _why_ versus _how_. |
| 43 |
* Please [](https://help.github.com/articles/closing-issues-via-commit-messages/reference any existing issue](https://help.github.com/articles/closing-issues-via-commit-messages/](https://help.github.com/articles/closing-issues-via-commit-messages/) in the commit message. |
| 44 |
|
| 45 |
Read [](http://chris.beams.io/posts/git-commit/this post](http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git-commit/) for more detail. |
| 46 |
|
| 47 |
## Submit Changes |
| 48 |
|
| 49 |
* Push your changes to a topic branch in your fork of the repository. |
| 50 |
* Open a pull request to the original repository and choose the correct original branch (probably `develop`) you want to patch. |
| 51 |
* Do not close any issue you referenced in your commit message. |
| 52 |
* If you have write access to the repository, do not directly push or merge your own pull-requests. Add the `[reviewmerge]` label when your branch is considered complete and let another team member review your pull request and approve. |
| 53 |
|
| 54 |
## License |
| 55 |
|
| 56 |
All submissions are agreed to be licensed under the same license as present in the repository. |
| 57 |
|
| 58 |
## Security |
| 59 |
|
| 60 |
There is no need to sign-off or GPG sign your commits. Tags (from 2.4.1 onwards) will be GPG signed. |
| 61 |
|
| 62 |
# Additional Resources |
| 63 |
|
| 64 |
* [](http://help.github.com/General GitHub documentation](http://help.github.com/](http://help.github.com/) |
| 65 |
* [](http://help.github.com/send-pull-requests/GitHub pull request documentation](http://help.github.com/send-pull-requests/](http://help.github.com/send-pull-requests/). |
| 66 |
* [](https://github.com/necolas/issue-guidelines/blob/master/CONTRIBUTING.mdRead the Issue Guidelines by @necolas](https://github.com/necolas/issue-guidelines/blob/master/CONTRIBUTING.md](https://github.com/necolas/issue-guidelines/blob/master/CONTRIBUTING.md) for more details, |
| 67 |
|
| 68 |
[issue ticket]: https://github.com/TGMPA/TGM-Plugin-Activation/issues |
| 69 |
[reviewmerge]: https://github.com/TGMPA/TGM-Plugin-Activation/labels/reviewmerge |
| 70 |
|
