|
| 1 | +# Contributing to the AWS Service Provider for Laravel |
| 2 | + |
| 3 | +Thank you for your interest in contributing to the AWS Service Provider for Laravel! |
| 4 | +We work hard to provide a high-quality and useful SDK for our AWS services, and |
| 5 | +we greatly value feedback and contributions from our community. Whether it's a |
| 6 | +new feature, correction, or additional documentation, we welcome your pull requests. |
| 7 | +Please submit your [issues][] or [pull requests][pull-requests] through GitHub. |
| 8 | + |
| 9 | +Jump To: |
| 10 | + |
| 11 | +* [Bug Reports](_#Bug-Reports_) |
| 12 | +* [Feature Requests](_#Feature-Requests_) |
| 13 | +* [Code Contributions](_#Code-Contributions_) |
| 14 | + |
| 15 | +## How to contribute |
| 16 | + |
| 17 | +*Before you send us a pull request, please be sure that:* |
| 18 | + |
| 19 | +1. You're working from the latest source on the master branch. |
| 20 | +2. You check existing open, and recently closed, pull requests to be sure that |
| 21 | + someone else hasn't already addressed the problem. |
| 22 | +3. You create an issue before working on a contribution that will take a significant |
| 23 | + amount of your time. |
| 24 | + |
| 25 | +*Creating a Pull Request* |
| 26 | + |
| 27 | +1. Fork the repository. |
| 28 | +2. In your fork, make your change in a branch that's based on this repo's master branch. |
| 29 | +3. Commit the change to your fork, using a clear and descriptive commit message. |
| 30 | +4. Create a pull request, answering any questions in the pull request form. |
| 31 | + |
| 32 | +For contributions that will take a significant amount of time, open a new issue to pitch |
| 33 | +your idea before you get started. Explain the problem and describe the content you want to |
| 34 | +see added to the documentation. Let us know if you'll write it yourself or if you'd like us |
| 35 | +to help. We'll discuss your proposal with you and let you know whether we're likely to |
| 36 | +accept it. |
| 37 | + |
| 38 | +## Bug Reports |
| 39 | + |
| 40 | +Bug reports are accepted through the [Issues][] page. |
| 41 | + |
| 42 | +Before Submitting: |
| 43 | + |
| 44 | +* Do a search through the existing issues to make sure it has not already been reported. |
| 45 | + If it has, comment your experience or +1 so we prioritize it. |
| 46 | +* If possible, upgrade to the latest release of the SDK. It's possible the bug has |
| 47 | + already been fixed in the latest version. |
| 48 | + |
| 49 | +Writing the Bug Report: |
| 50 | + |
| 51 | +Please ensure that your bug report has the following: |
| 52 | + |
| 53 | +* A short, descriptive title. Ideally, other community members should be able to get a |
| 54 | + good idea of the issue just from reading the title. |
| 55 | +* A detailed description of the problem you're experiencing. This should include: |
| 56 | + * Expected behavior of the SDK and the actual behavior exhibited. |
| 57 | + * Any details of your application environment that may be relevant. |
| 58 | + * Debug information, stack trace or logs. |
| 59 | +* If you are able to create one, include a Minimal Working Example that reproduces the issue. |
| 60 | +* Use Markdown to make the report easier to read; i.e. use code blocks when pasting a |
| 61 | + code snippet. |
| 62 | + |
| 63 | +## Feature Requests |
| 64 | + |
| 65 | +Open an [issue][issues] with the following: |
| 66 | + |
| 67 | +* A short, descriptive title. Ideally, other community members should be able to get a |
| 68 | + good idea of the feature just from reading the title. |
| 69 | +* A detailed description of the the proposed feature. |
| 70 | + * Why it should be added to the SDK. |
| 71 | + * If possible, example code to illustrate how it should work. |
| 72 | +* Use Markdown to make the request easier to read; |
| 73 | +* If you intend to implement this feature, indicate that you'd like to the issue to be |
| 74 | + assigned to you. |
| 75 | + |
| 76 | + |
| 77 | +## Code Contributions |
| 78 | + |
| 79 | +Code contributions to the SDK are done through [Pull Requests][pull-requests]. The list below are guidelines to use when submitting pull requests. These are the |
| 80 | +same set of guidelines that the core contributors use when submitting changes, and |
| 81 | +we ask the same of all community contributions as well: |
| 82 | + |
| 83 | +1. The SDK is released under the [Apache license][license]. Any code you submit |
| 84 | + will be released under that license. For substantial contributions, we may |
| 85 | + ask you to sign a [Contributor License Agreement (CLA)][cla]. |
| 86 | +2. We follow all of the relevant PSR recommendations from the [PHP Framework |
| 87 | + Interop Group][php-fig]. Please submit code that follows these standards. |
| 88 | + The [PHP CS Fixer][cs-fixer] tool can be helpful for formatting your code. |
| 89 | +3. We maintain a high percentage of code coverage in our unit tests. If you make |
| 90 | + changes to the code, please add, update, and/or remove tests as appropriate. |
| 91 | +4. Static code analysis with [PHPStan][phpstan] is automatically run on the `src` |
| 92 | + directory for submitted pull requests. If there is a case that needs to be |
| 93 | + ignored by static analysis, please update the `ignoreErrors` section in the |
| 94 | + `phpstan.neon` config file in your PR, and point out why this case warrants |
| 95 | + ignoring. |
| 96 | +5. If your code does not conform to the PSR standards, does not include adequate |
| 97 | + tests, or does not contain a changelog document, we may ask you to update |
| 98 | + your pull requests before we accept them. We also reserve the right to deny |
| 99 | + any pull requests that do not align with our standards or goals. |
| 100 | +6. If you would like to implement support for a significant feature that is not |
| 101 | + yet available in the SDK, please talk to us beforehand to avoid any |
| 102 | + duplication of effort. |
| 103 | +7. We greatly appreciate contributions to our User Guide. The docs are written |
| 104 | + as a [Sphinx][] website formatted with [reStructuredText][] (very similar to |
| 105 | + Markdown). The User Guide is located in another repository. Please go to the |
| 106 | + [awsdocs/aws-php-developers-guide](https://github.com/awsdocs/aws-php-developers-guide/). |
| 107 | + repository to suggest edits for the User Guide. |
| 108 | +8. If you are working on the SDK, make sure to check out the `Makefile` for some |
| 109 | + of the common tasks that we have to do. |
| 110 | + |
| 111 | + |
| 112 | +[issues]: https://github.com/aws/aws-sdk-php-laravel/issues |
| 113 | +[pull-requests]: https://github.com/aws/aws-sdk-php-laravel/pulls |
| 114 | +[license]: http://aws.amazon.com/apache2.0/ |
| 115 | +[cla]: https://github.com/aws/aws-cla/blob/master/amazon-single-contribution-license.txt |
| 116 | +[php-fig]: http://php-fig.org |
| 117 | +[cs-fixer]: http://cs.sensiolabs.org/ |
| 118 | +[phpstan]: https://github.com/phpstan/phpstan |
| 119 | +[sphinx]: http://sphinx-doc.org/ |
| 120 | +[restructuredtext]: http://sphinx-doc.org/rest.html |
0 commit comments