|
2 | 2 |
|
3 | 3 | Contributions are **welcome** and will be fully **credited**. |
4 | 4 |
|
5 | | -We accept contributions via Pull Requests on [Github](https://github.com/schulzefelix/laravel-adwords-targeting-idea-service). |
| 5 | +Please read and understand the contribution guide before creating an issue or pull request. |
6 | 6 |
|
| 7 | +## Etiquette |
7 | 8 |
|
8 | | -## Pull Requests |
| 9 | +This project is open source, and as such, the maintainers give their free time to build and maintain the source code |
| 10 | +held within. They make the code freely available in the hope that it will be of use to other developers. It would be |
| 11 | +extremely unfair for them to suffer abuse or anger for their hard work. |
9 | 12 |
|
10 | | -- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - Check the code style with ``$ composer check-style`` and fix it with ``$ composer fix-style``. |
| 13 | +Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the |
| 14 | +world that developers are civilized and selfless people. |
11 | 15 |
|
12 | | -- **Add tests!** - Your patch won't be accepted if it doesn't have tests. |
| 16 | +It's the duty of the maintainer to ensure that all submissions to the project are of sufficient |
| 17 | +quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used. |
13 | 18 |
|
14 | | -- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. |
| 19 | +## Viability |
15 | 20 |
|
16 | | -- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
| 21 | +When requesting or submitting new features, first consider whether it might be useful to others. Open |
| 22 | +source projects are used by many developers, who may have entirely different needs to your own. Think about |
| 23 | +whether or not your feature is likely to be used by other users of the project. |
17 | 24 |
|
18 | | -- **Create feature branches** - Don't ask us to pull from your master branch. |
| 25 | +## Procedure |
19 | 26 |
|
20 | | -- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. |
| 27 | +Before filing an issue: |
21 | 28 |
|
22 | | -- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. |
| 29 | +- Attempt to replicate the problem, to ensure that it wasn't a coincidental incident. |
| 30 | +- Check to make sure your feature suggestion isn't already present within the project. |
| 31 | +- Check the pull requests tab to ensure that the bug doesn't have a fix in progress. |
| 32 | +- Check the pull requests tab to ensure that the feature isn't already in progress. |
23 | 33 |
|
| 34 | +Before submitting a pull request: |
24 | 35 |
|
25 | | -## Running Tests |
| 36 | +- Check the codebase to ensure that your feature doesn't already exist. |
| 37 | +- Check the pull requests to ensure that another person hasn't already submitted the feature or fix. |
26 | 38 |
|
27 | | -``` bash |
28 | | -$ composer test |
29 | | -``` |
| 39 | +## Requirements |
30 | 40 |
|
| 41 | +If the project maintainer has any additional requirements, you will find them listed here. |
| 42 | + |
| 43 | +- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - The easiest way to apply the conventions is to install [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer). |
| 44 | + |
| 45 | +- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. |
| 46 | + |
| 47 | +- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
| 48 | + |
| 49 | +- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. |
| 50 | + |
| 51 | +- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. |
31 | 52 |
|
32 | | -**Happy coding**! |
| 53 | +**Happy coding**! |
0 commit comments