|
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/:vendor/:package_name). |
| 5 | +We accept contributions via Pull Requests on [Github](https://github.com/laravel-backpack/menucrud). |
6 | 6 |
|
7 | 7 |
|
8 | | -## Pull Requests |
| 8 | +## Bug Fixing & Enhancements |
| 9 | + |
| 10 | +We use the Github issue tracker for that. Here's the procedure we've settled upon so 2 people don't work on the same thing: |
| 11 | +- you find something that needs doing (say: unit tests for a certain package); |
| 12 | +- you check if there is already an issue for it (if there isn't, add one); |
| 13 | +- in that issue: |
| 14 | + - say you're working on it and it will be done in x hours or y days; |
| 15 | + - in that issue, assign the "working on it" label |
| 16 | + - assign yourself to the issue; |
| 17 | +- then comment/reference the issue in your pull request; |
9 | 18 |
|
10 | | -- **[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). |
11 | 19 |
|
12 | | -- **Add tests!** - Your patch won't be accepted if it doesn't have tests. |
| 20 | +## Pull Requests |
13 | 21 |
|
14 | | -- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. |
| 22 | +- **[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). It's ok to push non-PSR-2 code, but know that [StyleCI](https://styleci.io/) will convert it after the merge. |
15 | 23 |
|
16 | | -- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
| 24 | +- **Document any change in behaviour** - Make sure the `README.md` is still up-to-date with your modifs. |
17 | 25 |
|
18 | | -- **Create feature branches** - Don't ask us to pull from your master branch. |
| 26 | +- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
19 | 27 |
|
20 | 28 | - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. |
21 | 29 |
|
22 | 30 | - **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. |
23 | 31 |
|
24 | 32 |
|
| 33 | + |
| 34 | + |
25 | 35 | ## Running Tests |
26 | 36 |
|
| 37 | +The project does NOT have working tests right now, but it really should. If you want to help out, that's one of the most important things you can help with. |
| 38 | + |
27 | 39 | ``` bash |
28 | 40 | $ composer test |
29 | 41 | ``` |
|
0 commit comments