贡献指南
错误反馈
为了鼓励积极协作，Laravel 强烈地鼓励使用 Pull Request 指出修改的内容，而不仅仅只是反馈错误。「错误反馈」也可以用 PR 来提交失败测试。
如果你要提交错误反馈，你的问题应该包含标题和明确的问题描述，并尽可能多的提供相关的信息和演示该问题的代码示例。错误反馈的目的是让你和其他人可以轻松地重现并修复错误。
请记住，错误反馈的初衷是让其它有相同问题的人能够和你协作解决问题。不要指望反馈错误后会很快有人修复它。创建错误反馈是能帮助你和其他人开始着手修复问题的途径。
Laravel 源代码托管在 GitHub 上面，并且每个 Laravel 的项目都有自己的代码仓库：
核心开发讨论
你可以在 Laravel Ideas 的 问题板 中对 Laravel 现有的行为提出新特性或者改进建议。 如果你提出了一个新功能，我们希望请你至少完成该特性所需的一些代码。
关于 Bug，新功能和新功能的实现的非正式讨论会在 Laravel Discord 的 #internals 频道中进行。Laravel 的维护者 Taylor Otwell, 通常会在工作日的早上八点到下午五点 (UTC-06:00 或 America/Chicago) 出现在频道上，偶尔也会在其它时间出现在该频道。
分支选择
所有 Bug 修复都应该发送到最新的稳定版分支或当前的 LTS 分支上。Bug 修复决不应该发送到 master 分支，除非修复的是仅在即将发布的版本中发布的功能。
次要的完全向后兼容的新功能会发送到最新的稳定分支。
主要的新功能都应该发送到 master 分支，其中包含即将发布的 Laravel 版本。
如果你不确定你的功能符合主要的还是次要的，请在 Laravel Discord 的 #internals 频道中询问 Taylor Otwell。
编译资产
如果你提交的更改会影响已编译的文件，例如在 laravel/laravel 储存库中的 resources/sass 或者 resources/js 中的大多数文件，请不要提交已编译好的文件。因为它们尺寸较大，审查人员无法进行实际审查。这样可以被利用向 Laravel 中注入恶意代码，为了防止这种情况的发生，所有静态资产都由 Laravel 维护者生成并提交。
安全漏洞
如果你发现 Laravel 存在安全漏洞，请发送电子邮件给 Taylor Otwell: taylor@laravel.com。他会及时处理所有的安全漏洞。
编码风格
Laravel 遵循 PSR-2 编码规范和 PSR-4 自动加载规范。
PHPDoc
以下是正确写法的 Laravel 文档注释。请注意，@param 属性后跟两个空格、参数类型、两个空格，最后是变量名称：
/**
* 在容器中注册绑定。
*
* @param string|array $abstract
* @param \Closure|string|null $concrete
* @param bool $shared
* @return void
* @throws \Exception
*/public function bind($abstract, $concrete = null, $shared = false){ //}
StyleCI
别担心你的代码风格不够漂亮！在合并拉取请求后，StyleCI 将会自动把所有样式进行修正，再合并到 Laravel 存储库中。这使得我们更多的关注贡献的内容而不是代码风格。
