贡献指南

• 错误报告
• 支持问题
• 核心发展讨论
• 哪一个分支？
• 编译资源
• 安全漏洞
• 编码风格
  • PHPDoc
  • StyleCI
• 行为守则

错误报告

为了鼓励积极的合作，Laravel 强烈鼓励提交 pull request，而不仅仅是提交「Bug reports」。「Bug reports」也可以包含失败测试的 pull request 的形式发送。 只有在标记为“ready for review”（而不是处于“draft”状态）并且新功能的所有测试都通过时，才会审核pull请求。 停留在“draft”状态的、非活动的pull请求将在几天后关闭。

但是，如果您提交错误报告，您的问题应包含问题的标题和清晰的描述。 您还应该包含尽可能多的相关信息和演示问题的代码示例。 错误报告的目标是让您自己和其他人更容易复制错误并开发修复程序。

记住，创建错误报告是希望有相同问题的其他人能够与你合作解决它。不要指望这个错误报告会自动看到任何活动，也不要指望其他人会跳出来解决它。创建一个错误报告的目的是帮助你自己和其他人开始解决这个问题的道路。如果你想参与进来，你可以通过修复我们问题追踪器中列出的任何bug来帮助我们。你必须通过GitHub的认证才能查看Laravel的所有问题。

Laravel的源代码是在GitHub上管理的, 每个Laravel项目都有自己的存储库:

支持问题

Laravel的GitHub问题跟踪器并不是用来提供Laravel的帮助或支持的. 相反, 请使用以下渠道:

核心发展讨论

你可以在 Laravel 框架存储库的 GitHub 讨论区 中提出新功能或对现有 Laravel 行为的改进。 如果您提出一项新功能，请至少实现一些完成该功能所需的代码。

关于bug, 新功能, 和现有功能的实现的非正式讨论是在Laravel Discord服务器的#internals频道进行的. Taylor Otwell, Laravel的维护者, 通常会在工作日的早上8点到下午5点(UTC-06:00或美国/芝加哥)出现在这个频道, 其他时间也会零星出现在这个频道.

哪一个分支？

所有的错误修复都应该发送到最新的稳定分支或当前的LTS分支。除非是修复只存在于即将发布的版本中的功能，否则永远不要送至 "master "分支。

与当前版本完全向后兼容的次要**功能可能会发送到最新的稳定分支。

主要的新功能应该总是被送到 "master "分支，它包含了即将发布的版本。

如果你不确定你的功能是属于主要功能还是次要功能，请在Laravel Discord服务器的#internals频道询问Taylor Otwell。

编译资源

如果你提交的修改会影响到编译的文件，例如laravel/laravel仓库的resources/css或resources/js中的大部分文件，请不要提交编译的文件。由于它们的体积很大，它们实际上无法被维护者审查。这可能会被利用，成为向Laravel注入恶意代码的一种方式。为了防御性地防止这种情况, 所有的编译文件都将由Laravel维护者生成和提交.

安全漏洞

如果你在Laravel中发现了安全漏洞，请发邮件给Taylor Otwell，地址是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仓库中。这使我们能够专注于贡献的内容，而不是代码风格。

行为准则

Laravel的行为准则是由Ruby的行为准则衍生出来的. 任何违反行为准则的行为都可以报告给Taylor Otwell (taylor@laravel.com):