|
1 | 1 | # Contributing |
2 | 2 |
|
3 | | -Contributions are **welcome** and will be fully **credited**. |
| 3 | +Contributions are welcome and will be fully credited. |
4 | 4 |
|
5 | | -Please read and understand the contribution guide before creating an issue or pull request. |
| 5 | +Contributions are accepted via Pull Requests on [Github](https://github.com/wearedevtical/laravel-quran). |
6 | 6 |
|
7 | | -## Etiquette |
8 | | - |
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. |
12 | | - |
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. |
15 | | - |
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. |
18 | | - |
19 | | -## Viability |
20 | | - |
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. |
24 | | - |
25 | | -## Procedure |
26 | | - |
27 | | -Before filing an issue: |
28 | | - |
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. |
33 | | - |
34 | | -Before submitting a pull request: |
35 | | - |
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. |
38 | | - |
39 | | -## Requirements |
40 | | - |
41 | | -If the project maintainer has any additional requirements, you will find them listed here. |
| 7 | +## Pull Requests |
42 | 8 |
|
43 | 9 | - **[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 | 10 | - **Add tests!** - Your patch won't be accepted if it doesn't have tests. |
46 | | - |
47 | 11 | - **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. |
48 | | - |
49 | 12 | - **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
50 | | - |
51 | 13 | - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. |
52 | | - |
53 | 14 | - **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. |
54 | 15 |
|
| 16 | +## Running Tests |
| 17 | + |
| 18 | +``` bash |
| 19 | +$ phpunit |
| 20 | +``` |
| 21 | + |
55 | 22 | **Happy coding**! |
0 commit comments