Join MDN and developers like you at Mozilla's View Source conference, 12-14 September in Berlin, Germany. Learn more at https://viewsourceconf.org

贡献代码到 Mozilla 代码库

这个页面将助你迈出向 Mozilla 贡献的第一步欢迎你,我们很高兴见到你!:)

需要帮助吗?

Mozilla社区欢迎您加入到我们中来。如果您碰到任何困难,请在这里寻求帮助#introduction chat room on irc.mozilla.org, 当您遇到非常棘手的问题,还可以联系Kyle Huey at khuey@mozilla.com

对我的技能有什么要求?

Mozilla 是一个庞大的项目,我们相当乐意接受贡献者们运用各种不同技能贡献。

  • 如果您精通C++, 那么您可以为Firefox的核心层、Firefox OS 或者其他的Mozilla产品贡献代码;
  • 如果您精通JavaScript 或者HTML/CSS, 那么您可能对Firefox前端, Gaia或者Firefox OS的应用层感兴趣;
  • 如果您精通Java, 那么我们推荐Firefox Mobile领域;
  • 如果您熟悉 Python,您可以助力我们的 Web 服务,包括 Firefox 同步和 Persona。
  • 如果您熟悉Make, shell, Perl或者Python, 请关注我们的编译系统;
  • 如果您熟悉C, 那么您可以为Mozilla代码库所使用的一系列底层或第三方库贡献代码;
  • 当然,除了编程,还有其他多种途径可以为Morzilla做出贡献。如果您希望在设计,服务支持,语言翻译,测试,等其他方面做出贡献,请点击Volunteer Opportunities page.

也许您希望开始学习编程?非常好!希望 the Webmaker program 可以帮到您,  并且在Mozilla开发者网络上还有更多资源!

步骤 1 - 构建 Firefox、Firefox OS、Thunderbird 或其它应用程序

如果你想助力 Firefox、Thunderbird 或 Firefox OS,请跟着我们的构建 Firefox构建 Thunderbird构建  Firefox OS 的整套简单指导来操作。很简单,但可能需要一些时间,因此你或许想要在正在构建的时候下进行下一步。更多构建指南请点这里

对于其他产品,你或许不需要构建任何东西。

步骤 2 - 找些事情做做

修复你无法忍受的地方

如果有一些你想要修复Firefox, Thunderbird, 或者其他你最喜欢的Mozilla应用的缺点,这些都是很好的出发点。可以通过以下途径来着手:

  • 在 bugzilla中搜索关键词.
  • 使用组件列表找出你发现问题的bugzilla组件,在bugzilla上浏览该组件的相关bugs。
  • 在irc.mozilla.org的 #introduction 或 #developers 频道提问.

对新手,找个我们已发现的bug(练手)是一个不错的选择。

由于Bugzilla中有超过1百万bugs而让人觉得难以入手,于是我们创建了这些bug列表来使问题变简单一些。

  • "Good" First Bugs 是带你进入Mozilla生态最好的方法。他们是一些很小的修改-有时小到几行代码-但从这个地方入手是学习建立开发环境,浏览Bugzilla乃至为Mozilla代码库添砖加瓦的良方。
  • Mentored bugs 则是更具挑战的,但是有一个督导来帮你弄懂这个过程。一般来说,是有足够的bug信息来让你开始工作。什么时候你需要帮助,通过bug里边的IRC或email联系督导。当你完成了修复,他们会帮你把你的代码合并到(主)代码中。
  • Student Projects 是更大的工程,因此可能适合有信誉的大学生,当然,如果你不是一名学生,你也仍然可以随心修改一个或多个bug。我们维护两条分支,一个用于项目已存在的代码另外一个用于实现新应用。

步骤 3 - 修复 Bug

我们把这些留给你勤劳的双手,当然,我们也提供给你一些资源来帮你完成这些工作。

步骤 4 - 审查您的代码

一旦你完成修复了一个bug,就把附上补丁到bug并寻求检查。通过点击你附件的Details连接,可设置检查标签以标记需要review。进入在文字页面出现的查阅者的bugzilla ID(要么是他们的email或者他们提供的唯一名称标识)。添加bugzilla ID是非常重要的步骤,否则你的请求会被遗漏。然而,你如何找出到合适的人来做review呢?

  • 如果你解决的是一个mentored bug,那就询问你的督导,他们知道或者很容易找到review的人。
  • 运行 hg blame 并查看有谁接触了你工作的那些函数-他们将是合适的人选。
  • bug 本身(注释说明)可能包含一个合适人选来请求做review。
  • 相似主题是否有相关的bugs?如果有的话,之前相似主题的bugs的reviewer可能是个好的选择。
  • 我们有一个过时的模块列表,它列出了模块的开发者和工作者,这些人中的某些可能是合适的选择。最差的情况下,就设置模块的拥有者为reviewer,如果他们没有时间,就请他们在bug评论里挑选一个合适人选。

Step 4b - 跟踪负责

一旦你申请review,检阅人员一般会在一到两天时间内给你反馈,review补丁或者,如果他们把这个review添加到工作列表,表示他们会对它进行review。如果reviewer在一段时间内无响应,不要惧于告知下他们。只需要添加一个评论到bug,评论一句‘review  ping?’,检查下bug的“Need more information from:” 框内并添加reviewer的名字,如果他们在一两天内没有反应,你可以通过#介绍或者#开发的IRC频道寻求帮助,或者直接联系Mike Hoye 。

步骤 5 - 回应代码审查

对于大多数的contributors - 和长期活跃的Mozillians来说 - 你补丁的第一次review评价将是r-,这并不意味着你做了很差的工作,而说明你代码在合并到项目分支前仍有一些工作需要做。你的补丁可能需要做一些修改 - 可能是小的也可能是大部分修改 - 并且你的reviewer将给你些下一步工作指导。

这是一个重要的过程,因此不要因此丢掉自信!作为拥有一份长期代码库和数百万使用者,细心和专注帮助contributors合并强壮的补丁是Mozilla 项目的基石。根据你的reviewer的说明进行修改;如果你不确定修改,一定要问!把新的补丁再一次附在bug上,并申请同一reviewer再一次进行审查。如果他们给你的评论是r+,这就意味着你的bug被接收到项目tree中。

步骤 6 - 确保将代码合并到主代码中

一旦你的补丁得到r+的评论,它就准备使用了。但在合并到项目分支前,你的补丁将需要通过我们的"try server"实现一次成功运行以保障它不会引起非预期的退化。你的督导或者审阅你补丁的人会帮忙完成那些工作,如果你现在还没有try server的权限。

一旦你获得一次成功的try server 运行,你的补丁会被标记可行,并准备通过在bug顶部添加checkin-needed 关键字到“keywords”域提交。一个友好的具有提交权限的Mozillian将快速的push你的补丁到库中,并更新bug。如果你的补丁已经通过Mozilla's的自动测试,不久后将会合并到主分支而成为我们nightly builds的一部分。

步骤 7 - 重复以上的步骤

非常感谢。你已经修改好你的第一个bug,开源web由于它而更加强壮。但不要停下来。

回到第三步,要做的还很多。你的督导可以推荐一个新的bug给你来解决,或者你可以自己找一个你感兴趣的。既然你已经修复了你第一个bug,你应该收到level 1的访问库权限,因此你可以push 到try server并得到你修改内容在多平台自动运行反馈结果。在修复一系列bugs之后,你会获得level 3的权限,也就是说你可以在得到r+的评分后,自己push 代码到分支。

更多信息

我们正改进这个页面信息以面向项目新手,很快,我们将集成这些页面的信息,不过,在那之前你可能会发现现在的形式很有趣。

文档标签和贡献者

 此页面的贡献者: colin-zhou, Zuozhuo, Aetf, JDu, wanglong, xcffl
 最后编辑者: colin-zhou,