贡献引导

错误反馈

为了鼓励积极协作,Laravel 强烈地鼓励使用 Pull Request 指出修改的内容,而不仅仅只是反馈错误。「错误反馈」也可以用 PR 来提交失败测试。

如果你要提交错误反馈,你的问题应该包含标题和明确的问题描述,并尽可能多的提供相关的信息和演示该问题的代码示例。错误反馈的目的是让你和其他人可以轻松地重现并修复错误。

请记住,错误反馈的初衷是让其它有相同问题的人能够和你协作解决问题。不要指望反馈错误后会很快有人修复它。创建错误反馈是能帮助你和其他人开始着手修复问题的途径。

Laravel 源代码托管在 GitHub 上面,并且每个 Laravel 的项目都有自己的代码仓库:

核心开发讨论

你可以在 Laravel Ideas 的 issue board 中对 Laravel 现有的行为提出新特性或者改进建议。 如果你提出了一个新功能,我们希望请你至少完成该特性所需的一些代码。

关于 Bug,新功能和新功能的实现的非正式讨论会在 LaraChat Slack团队的 #internals 频道中进行。Laravel的维护者 Taylor Otwell, 通常会在工作日的早上八点到下午五点(UTC-06:00 或 America/Chicago) 出现在频道上,偶尔也会在其它时间出现在该频道。

选择分支?

所有 bug 修复都应该发送到最新的稳定版分支或当前的 LTS 分支 (5.6) 上。Bug 修复 绝不 应该发送到 master 分支,除非修复的是 仅在即将发布的版本中发布的功能。

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

主要 的新功能都应该发送到 master 分支,其中包含即将发布的 Laravel 版本。

如果你不确定你的功能符合主要的还是次要的,请在 LaraChat Slack 团队的 #internals 频道中询问 Taylor Otwell。

安全漏洞

如果你发现 Laravel 存在安全漏洞,请发送电子邮件给 Taylor Otwell: taylor@laravel.com。所有的安全漏洞他将会及时解决。

代码规范

Laravel 遵循 PSR-2 编码规范和 PSR-4 自动加载规范。

PHPDoc

以下是正确写法的 Laravel 文档注释。请注意,@param 属性后跟两个空格、参数类型、两个空格,最后是变量名称:

  1. /**
  2. * Register a binding with the container.
  3. *
  4. * @param string|array $abstract
  5. * @param \Closure|string|null $concrete
  6. * @param bool $shared
  7. * @return void
  8. */
  9. public function bind($abstract, $concrete = null, $shared = false)
  10. {
  11. //
  12. }

StyleCI

别担心你的代码风格不够漂亮!在合并拉取请求后,StyleCI 将会自动把所有样式进行修正,再合并到 Laravel 存储库中。这使得我们更多的关注贡献的内容而不是代码风格。

本文章首发在 LearnKu.com 网站上。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接 我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。