贡献指南

缺陷报告

为了鼓励促进更加有效积极的合作，Laravel 强烈鼓励使用 GitHub 的 pull requests，而不是仅仅报告缺陷，「缺陷报告」也可以通过一个包含失败测试的 pull requests 的方式提交。

然而，如果你以文件的方式提交缺陷报告，你的问题应该包含一个标题和对该问题的明确说明，还要包含尽可能多的相关信息以及论证该问题的代码样板，缺陷报告的目的是为了让你自己和其他人更方便的重现缺陷并对其进行修复。

记住，缺陷报告被创建是为了其他人遇到同样问题的时候能够和你一起合作解决它，不要寄期望于缺陷会自动解决抑或有人跳出来修复它，创建缺陷报告是为了帮你自己和别人走上修复问题之路。

Laravel 源码通过 Github 进行管理，每一个 Laravel 项目都有其对应的代码库：

• Laravel Application
• Laravel Art
• Laravel Documentation
• Laravel Cashier
• Laravel Cashier for Braintree
• Laravel Envoy
• Laravel Framework
• Laravel Homestead
• Laravel Homestead Build Scripts
• Laravel Horizon
• Laravel Passport
• Laravel Scout
• Laravel Socialite
• Laravel Telescope
• Laravel Website

核心开发讨论

你可以在issue board上提议新功能或者优化已有功能，如果是新功能的话请至少实现部分代码以便完成新功能开发。

关于 Laravel 的 bug、新功能、以及现有功能实现的非正式讨论可以在 Laravel Discord server 的 #internals 频道进行。Taylor Otwell，Laravel 框架的维护者，通常在工作日的上午8点到下午5点（美西时间或芝加哥时间）在线，其它时间也可能偶尔在线。

哪个分支？

所有的 bug 修复应该被提交到最新的稳定分支，永远不要把 bug 修复提交到 master 分支，除非它们能够修复下个发行版本中的特性。

当前版本中完全向后兼容的次要特性也可以提交到最新的稳定分支。

重要的新特性总是要被提交到 master 分支，包括下个发行版本。

如果你不确定是重要特性还是次要特性，请在 Laravel Discord server 的 #internals 频道咨询 Taylor Otwell。

编译前端资源

如果你提交的文件更改会影响前端编译文件，通常这种文件位于 1aravel/laravel 仓库的 resources/sass 或 resources/js 目录下，不要提交编译后的文件，因为它们的尺寸往往很大，框架维护者没法对其进行代码审查（Code Review）。不怀好意的人可能会借此注入恶意代码到 Laravel 中，为了避免这种情况发生，仓库里所有编译后的文件只能由 Laravel 框架维护者生成和提交。

安全漏洞

如果你在 Laravel 中发现安全漏洞，请发送邮件到 taylor@laravel.com，所有的安全漏洞将会被及时解决。

编码风格

Laravel遵循 PSR-2 编码标准和 PSR-4 自动载入标准。

PHPDoc

下面是一个有效的 Laravel 文档区块示例，注意到 @param 属性前面有两个空格，参数类型前有两个空格，最后是参数名称，也有两个空格：

/**
 * Register a binding with the container.
 *
 * @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 仓库代码一致，从而让我们更加专注于代码内容而非风格。