[译]14种参与开源项目的方法，不需要你成为一名编程天才或者摇滚明星

摘要: 免责申明（必读！）：本博客提供的翻译原稿均来自于互联网，仅供英语学习之用。若转载，请不要移除本申明。由于英语翻译水平有限，如产生任何纠纷，均与本博客无任何关系。谢谢合作！原文地址：http://www.softwarequalityconnection.com/2012/03/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/　

　　很多人想要参与开源项目却不知道如何开始。如果你对自己的技术没有信心，下面的方法能帮助你解决这个问题。

　　开源软件已经改变了计算机和世界，你们许多人想要对此做贡献。不幸的是，很多人觉得加入一个项目是难于逾越的障碍，他们被自己的想象给吓到了。我经常听到人们说他们很想做贡献但是不能，因为如下的三个原因：

• “我不是一个非常好的程序员。”
• “我没有很多时间投入。”
• “我不知道做什么项目。”

　　当你寻找做贡献的机会时，记住如下三个核心原则：

• 项目需要各种技术和不同专业水平的人做贡献；
• 再小的贡献仍比没有多；
• 再好的项目也是从你已经在用的东西开始制作。

　　我观察到在开源新人中最具破坏性的想法是为开源做项目，你得成为某类天才程序员。这不是真的。当然，有些人在开源世界被视为摇滚明星，他们可能确实是天才程序员。然而，我们中的绝大多数都不是。我们只是把事情做完的人。有时候我们做一点，有时候我们做很多。有时候事情是编程，有时候不是。 

　　大多数使我们开始开源工作的是实际的工作，为项目花时间实现一些事情。大多数事情不需要有如Perl的创造者Larry Wall或者如Rails的创造者David Heinemeier的智力或视野。设计一种新的语言或者新的web框架获得灵感，但是让项目像Perl和Rails这么成功的其他因素是汗水。这个工作可能并不能获得所有的荣誉，但是它是必须的，经过一段时间后，他人就会注意到你的贡献。

  

Start listening开始倾听

　　开源中的任何事情都涉及其他人。你要寻找一支参与团队，这意味着你了解这个社区以及它如何运作。进入项目中说“Hi，这是我对这项目的想法，这个项目应该这么做”通常这并不是一件好事。一些项目也许欢迎这类型的态度，但是如果项目已经运行了一段时间，接受这种态度的机会将很小。倾听是了解项目需求最好的方式。

　　加入邮件列表：对于很多项目来说，邮件列表是沟通有关该项目发展的主要渠道。在大项目中，有很多可选择的邮件列表。举个例子，PostgreSQL项目的邮件列表页面上有不下12种面向用户的列表和6个开发人员列表。我建议你从查看主要面向用户的列表和核心开发人员列表开始倾听。

　　跟随博客：博客主要由核心开发人员撰写，通常会包含一些信息：关于未来的版本将会有哪些改变和它会达到什么目标。一个行星网站会从很多关于这个项目的源中收集新闻和博客条目。如果存在这样一个行星网站，如http://planet.gnome.org或者http://planet.mysql.com，他们会这样开始——仅仅是在Google中搜索“planet <projectname>”。

　　加入IRC频道：许多开源项目有专门互联网中继聊天频道给各处的开发者和使用者讨论项目的问题和发展。打开该项目的页面，查询相关细节包括网站建立的可呼叫的频道和IRC网络。

 

Work with tickets 处理问题清单

　　代码是任何一个开源程序的核心，但是不要认为编写代码是唯一能做贡献的途径。尤其在创建新特性和修复bug时，代码和系统的维护经常被忽视。这些方面是你迈进一个开源项目的简单途径。

　　大多数项目会有一个公开可见的问题清单系统，链接往往在项目网站的首页并且该问题清单还包含在文档中。它是使用者和开发者沟通的主要渠道。保持这个系统的实时性是一种帮助该项目的好方法。你也许需要在这个系统中获得特殊的允许，不过当你说你想帮忙处理这些问题留言，大多数项目领导人会很乐意给你这些允许。

　　诊断bug：bug通常记录得不充分。诊断和筛选bug可以在找出该问题发生的详细情况上帮助开发人员节省时间。如果一个用户发表疑问，“这个软件在我做X的时候无法运作”，就得花一些时间去解决导致这类问题发生的详细情况。这是不是复现的？你可以设置一系列步骤导致问题复现么？你可以缩小问题的范围吗，例如仅仅发生在一个浏览器而不在其他浏览器发生，或者只是一个发行版本的问题而不是所有版本？

　　即使你不知道什么导致这些问题发生，你在减少这种情况上的努力也不会白费，这会让其他人更容易修正这问题。你的任何发现都可以添加到bug系统的清单上，让所有看到它。

　　关闭已经修正的bug：通常在代码库里修正了bug，但是在问题清单系统里并没有更新已发布的bug清单。解决这些零碎的事可能十分耗时，但是对整个项目来说却是十分有价值的。

　　一开始可以从问题清单系统中查询停留一年以上的问题，看看这个bug是否仍存在。检查项目发布的更新日志，确定这个bug是否已经修复可以关闭。如果这个bug的修复是大家熟知的，在问题清单中记录这个版本号并关闭这个bug。

　　试着用软件的最新版本重建这个bug。如果用最新版不能重建它，在问题清单中记录并关闭它。但是如果它依旧存在，仍得留在问题清单中，使bug保持在打开状态。

 

Working with code 编写代码

　　不同经验水平的程序员都能对项目中的代码提供帮助。不要以为你必须成为一个编程天才才能对你喜欢的项目提供真正的贡献。

　　如果你参与到代码修正的工作中，就要从这个项目的代码贡献者那儿研究他的方法。每个项目都有它自己的工作流，所以在你打算提交代码前需要知道怎么做。

　　举个例子，PostgreSQL项目在它的流程中是十分严格的：代码修正将以一小张表格的方式发送至邮件列表上，供核心开发人员详细审查这个更改的各个方面。相反，像Parrot项目是很容易得到将代码提交到代码库的权利。如果项目使用GitHub，也许都会有一个工作流是使用pull请求，这是GitHub的特征。没有任何两个项目会是相同的。

　　无论何时你修改代码，确保你像一个负责的社区成员并使你的代码风格符合代码库的其他部分。你添加或者修改的代码应该看起来想其他部分的代码。你也许不喜欢这样的支撑风格或者是对缩进的处理，但是提交不符合现有标准的代码变更是粗鲁不友好的。这就像说，“我不喜欢你的风格，我觉得我的更棒，所以你应该按我的方式做”。

　　测试一个测试版或者发布版的替补版本：任何支持多平台运行的项目会有各种各样可移植性的问题。当一个即将发布版和一个测试或者发布版的替补版本公布，这个项目的领导人总是希望它能被许多不同平台的人测试。你可以成为这些人中的一个，帮助确保软件包在你的平台运行正确。

　　很典型地是，你可能仅需要下载、构建和测试软件，但是如果你在一个罕见的发布(译：不知是否理解正确)或者硬件上运行，这对项目的价值是巨大的。仅报告构建和测试的运行情况就能帮助项目领导人知道即将发行的版本是可靠的。

　　修复bug：通常贡献者都是想从代码的工作开始。这很简单：在问题清单系统中找一个听起来有意思的bug并尝试在代码中修复它，如果修改适当，就可以在文件中修正代码。

　　在测试集中添加一个测试来检测你修正的代码点，这是一个好想法；一些项目修复bug需要包含测试。当你在不熟悉的代码库闲逛时，要注意！即使你不能修复这个bug，也可以在这个问题单中记录你在尝试修复时的发现。你的发现可以帮助你的后来者。

　　写测试：大多数项目都有一个测试集用于代码测试，但是很难想象一个测试集添加了足够多的测试。使用测试代码覆盖率的工具，如针对C的gcov或者针对Perl的Devel::Cover来识别一些没有被测试集测试到的区域。接着，添加一个测试到测试集来覆盖它。

　　消除编译器警告：在构建很多基于C的项目过程中，屏幕上经常会出现一些奇怪的编译器标识警告。这些警告通常不是一个问题指示，但是它们看起来像个问题。太多的警告会让编译器听起来像是“狼来了”。

　　查看该代码实际是否能隐藏一个bug。如果不能，则修改源码有助于隐藏这些假的错误报告。

　　添加评论：当你挖掘代码时，你可能会发现一些点十分困惑。碰巧的是如果你感到困惑，其他人往往也是如此。在代码中记录它们，并提交一个补丁。

 

Work with documentation 编写文档

　　文档显然是项目的一部分，却容易被忽视。它编写的角度是从那些对该项目熟悉的人的角度，而不是根据一些刚刚接触项目的人的眼光。如果你曾经阅读过一个项目的文档，“就像这本手册预期的那样我已经知道怎么使用该软件包”，你会知道我在说什么。通常一些刚接触项目的人能指出文档中的缺陷，这是那些同项目亲密接触的人所注意不到的。

　　创建示例：任何一个项目都没有太多怎么做的例子。不管是web API、程序库、如Gimp的GUI应用程序或者是一个命令行工具，一个正确使用的示例比一页页说明文档更能清楚、快速地解释软件正确的用法。

　　对一个API或者库来说，创建示例程序可以使用工具。该程序甚至可以从你写好的代码中提取，然后缩减至剩下必备功能。对于工具来说，要展示你在日常生活中使用它的真实例子。如果你是以视觉为导向，你可以考虑为重要的过程创建屏幕截图，例如怎样安装该应用程序。

 

Work in the community 服务社区

　　开放源码仅是部分关于代码的工作。社区才能试开源事业运作。这里有些方法可以帮助你创建它。

　　回答问题：帮助创建社区的最好方式就是帮助他人。回答问题，尤其是从刚参与的人那边得到的问题，对帮助项目成长是至关重要。你可以花时间帮助菜鸟，即使你觉得他问的问题可以很简单地扔回一句“RTFM”（去读他妈的手册），但在未来他可能会成为另一个活跃的社区成员。每个人都是从一个点开始的，而我们做项目的话就需要有不断的有拥有积极创新精神的人加入。

　　写博客：如果你有博客，就基于你正在使用的项目写一些体验，说说在软件使用中你遇到的问题和你怎么解决的。你能通过两种方面提供帮助，一方面是帮助你周围专注于该项目的其他人，另一方面是做记录使未来和你有相同问题的人可以通过搜索网页找到问题答案。（一个关于你的技术探索博客是一种非常棒的方式展示你在实际生活中对软件的一些思考体会，下次在找工作可以用到它。）

　　改善网站：绝大多数程序员都是非常蹩脚的平面设计师，这是一个罕见的项目网站，因此不能用设计部门的一些帮助。如果你有页面设计的技能就可以帮忙改善网站，而且对于项目面向公众的形象花些时间是值得的。也许项目里可以使用图像改革或者用一个logo去标识。在社区中可能缺少这些技能，但如果我的一些平面设计能给我的项目网站提供帮助，我知道我会很乐意去做。

　　最重要的是，倾听你周围的人在讨论什么，看看你是否能判断出一个迫切需求。举个例子，最近在Parrot的开发人员邮件列表里决定使用GitHub作为问题清单系统，废弃他们已安装的Trac(PS:开源应用，为软件开发项目需要而集成了Wiki和问题跟踪管理系统的应用平台)。一些人反对这项举措因为没有办法把已有的问题清单转至GitHub系统。经过一天的反复争论，我尖着嗓子说“如果我写个转换器呢？”人们对于这个想法很激动。我花时间为450多个问题单写了转换程序，所以我们没有遗漏任何问题的历史记录。这是一个巨大的成功。我投入到这部分工作，核心的开发人员则关注Parrot业务方面的运作。

　　如果我们看看过去编写一个新项目特性的明确步骤，就会发现有如此之多的方法为开源做贡献。每个使用开源的人可以将他们的技术带到社区中并使开源一直成为计算机重要的一部分。

 

PS:终于完成了。。拖了老久。谢谢Iven以及他那位朋友的帮忙~~