|
1 | 1 | # Contributing Guide |
2 | 2 |
|
3 | | -This page contains guidelines for contributing to the Laravel.IO project. Please review these guidelines before submitting any pull requests to the project. |
4 | | - |
5 | | -This contributing guide is based on the original [Laravel Contribution Guide](https://github.com/laravel/framework/blob/4.1/CONTRIBUTING.md). |
6 | | - |
7 | | -## Which Branch? |
8 | | - |
9 | | -The current 2.x version of the website is in maintenace mode. This means that only bugfixes and small improvements will be accepted for the current version. New features will be accepted only if they are needed on short-term basis. All changes targeting the current version should be sent to the `develop` branch. |
10 | | - |
11 | | -New features need to be sent to the [`3.0`](https://github.com/LaravelIO/laravel.io/tree/3.0) branch. |
| 3 | +We welcome contributions to the Laravel.IO project. Please read the following guide on how to in pull requests. |
12 | 4 |
|
13 | 5 | ## Pull Requests |
14 | 6 |
|
15 | | -The pull request process differs for new features and bugs. Before sending a pull request for a new feature, you should first create an issue with `[Proposal]` in the title. The proposal should describe the new feature, as well as implementation ideas. The proposal will then be reviewed and either approved or denied. Once a proposal is approved, a pull request may be created implementing the new feature. |
16 | | - |
17 | | -Pull requests for bugs may be sent without creating any proposal issue. If you believe that you know of a solution for a bug that has been filed on GitHub, please leave a comment detailing your proposed fix. |
18 | | - |
19 | | -### Feature Requests |
20 | | - |
21 | | -If you have an idea for a new feature you would like to see added to Laravel, you may create an issue on GitHub with `[Request]` in the title. The feature request will then be reviewed by [@driesvints](https://github.com/driesvints). |
| 7 | +- **Feature requests** first need to be discussed and accepted by the community through an issue before sending in a pull request |
| 8 | +- **Bug fixes** should contain [regression tests](https://laracasts.com/lessons/regression-testing) |
| 9 | +- All pull requests should follow the [coding standards](#coding-standards) |
| 10 | +- Pull requests will be merged after being reviewed by [the maintainers](readme.md#maintainers) |
| 11 | +- Please be respectful to other contributors and hold to [The Code Manifesto](http://codemanifesto.com/) |
22 | 12 |
|
23 | 13 | ## Coding Standards |
24 | 14 |
|
25 | | -The Laravel.IO project follows the [PSR-2](http://www.php-fig.org/psr/psr-2/) coding standards. Although the current codebase isn't compliant yet, pull requests which contain new code are required to adhere to these coding standards. |
26 | | - |
27 | | -### Docblocks |
28 | | - |
29 | | -The use of docblocks is required. New code which isn't documented with docblocks for functions will be refused. |
30 | | - |
31 | | -When writing `@param` or `@return` statements it's encouraged to use the full namespace instead of the reference. This is to improve the readability to know immediatly which type of object you're dealing with. |
| 15 | +- Follow the [PSR-2 Coding Standard](http://www.php-fig.org/psr/psr-2/) |
| 16 | +- Add tests because we generally don't accept pull requests without them |
| 17 | +- Write the full namespace in DocBlocks for `@param`, `@var` or `@return` tags |
32 | 18 |
|
33 | 19 | ## Testing |
34 | 20 |
|
35 | | -The current test suite is still being worked on but we encourage you to write tests for new code and/or features. |
36 | | - |
37 | | -All tests can be run with the following command. Make sure to run this inside the Homestead box. |
| 21 | +All tests can be run with the following commands. Make sure to run this inside the Homestead box. |
38 | 22 |
|
| 23 | + $ vendor/bin/phpspec run |
39 | 24 | $ vendor/bin/phpunit |
0 commit comments