# 非程序员可以做的事
## 从倾听开始

开源的本质是人与人之间的合作。  
你想要加入一个团队，就必须了解这个社区以及它是如何运作的。  
直接进入一个项目并说“嗨，我认为这个项目应该做XXX”通常不会被很好地接受。  
某些项目可能欢迎这种方式，但如果项目已经运行一段时间，这种态度很难被采纳。  
**倾听是了解项目真正需求的最佳方式。**

1. **加入邮件列表**：  
对于许多项目来说，邮件列表是关于项目开发的主要沟通渠道。在大型项目中，可能会有很多不同的邮件列表可供选择。例如，PostgreSQL 项目在其邮件列表页面上就有不少于 12 个面向用户的列表和 6 个开发者列表。  
建议你一开始关注主要的用户列表和核心开发者列表来“听听看”。

2. **关注博客**：  
核心开发人员维护的博客通常会分享有关未来版本的计划，以及达成这些目标的过程。一个叫做 planet 的网站会汇集来自多个相关来源的新闻和博客内容。  
如果某个项目有 planet 网站，比如 planet.gnome.org 或 planet.mysql.com，请从那里开始。只需在 Google 中搜索  "planet <projectname>" 即可。

3. **加入 IRC 频道**：  
许多开源项目都有专属的 IRC（互联网中继聊天）频道，开发者和用户会在里面讨论问题与开发进度。在项目的官方网站上通常可以找到 IRC 频道的名称和所在网络的信息。

**处理工单系统**  
代码是任何开源项目的核心，但不要以为只有写代码才算是贡献。  
代码的维护及其周边系统往往在开发新功能或修复 bug 的过程中被忽略。  
这些部分是你进入项目的良好切入点。  
大多数项目都有公开的故障工单系统，通常在项目主页和文档中就能找到链接。  
它是用户与开发者之间的主要沟通渠道。  
保持工单系统的更新就是一种很有价值的贡献。  
你可能需要获得该系统的特别权限，一旦你表示出愿意协助维护，项目负责人通常会很乐意为你开放权限。

4. **诊断 bug**：  
很多 bug 报告都不够详细。  
协助诊断并分析 bug 可以大大节省开发者排查问题的时间。  
比如用户报告“我做了 X 操作，软件就坏了”，你可以尝试复现问题，找出具体触发条件。  
这个问题是可以重复触发的吗？能不能提炼出一套步骤重现问题？是否只在某些浏览器或操作系统中才出现？

即使你不清楚问题的根本原因，但你做出的分析工作，也会让其他人更容易去修复它。  
无论你发现了什么，请将其记录在工单系统中，方便所有人查看。

5. **关闭已修复的 bug**：  
有些 bug 虽然已经在代码中修复，但对应的工单却没有更新状态。  
清理这些“陈年工单”虽然耗时，但对整个项目非常有帮助。

你可以从查询一年以前的工单开始，检查这些 bug 是否仍然存在。  
阅读项目的更新日志，确认 bug 是否已被修复。  
如果确定已修复，请在工单中注明修复版本并关闭工单。

也可以尝试使用最新版本重现这个 bug。  
如果无法复现，请在工单中注明并关闭；如果仍存在，也请更新工单说明并保留为“打开”状态。

## 参与代码工作

不同经验水平的开发者都可以为项目贡献代码。  
不要认为只有编程大神才有资格参与贡献。

如果你的工作涉及代码更改，请先了解项目是如何接受代码贡献的。  
每个项目的工作流都不同，因此在提交代码之前请先询问清楚流程。

例如，PostgreSQL 项目对代码提交要求非常严格：必须以补丁形式发送到邮件列表，由核心开发者详细审查。  
而 Parrot 项目则相对宽松，很容易就能获得代码库的提交权限。  
如果项目托管在 GitHub 上，可能还会使用 pull request 的工作流。  
没有两个项目是完全相同的。

每当你修改代码时，请务必遵守已有代码风格，使你提交的代码看起来就像是原生的一部分。  
即使你不喜欢某种括号或缩进方式，也不应擅自改变已有风格。  
这就像在说：“我不喜欢你们的风格，我的更好，你们应该改成我的。”

6. **测试测试版或候选版本**：  
如果一个项目支持多个平台，那发布前的可移植性测试就至关重要。  
当项目发布 beta 或 RC（Release Candidate）版本时，项目负责人希望有人能在各种平台上进行测试。  
你就可以成为其中一员，帮助确认在你的环境下也能正常运行。

通常你只需下载、构建并运行软件即可。  
尤其当你使用的是较为冷门的操作系统或硬件时，你的反馈对项目非常宝贵。

7. **修复一个 bug**：  
这是很多想写代码的新手常见的起点。  
很简单：在工单系统中找一个感兴趣的问题，尝试去修复它。  
如果合适，可以在代码中添加注释记录你的修改；如果项目有测试套件，最好也为你修复的 bug 添加测试用例。  
即便你没能修复 bug，也请将你调查的结果写进工单中，这对后来的人是很有帮助的。

8. **编写测试用例**：  
大多数项目都有测试套件，但几乎没有哪个测试覆盖是“完美”的。  
可以使用测试覆盖工具（如：C 的 gcov，Perl 的 Devel::Cover）找出哪些代码尚未被测试。  
然后为这些部分添加测试用例。

9. **消除编译警告**：  
许多基于 C 的项目在编译时会有很多警告信息。  
虽然多数情况下这并不影响程序运行，但会制造混乱或误导。  
你可以排查警告背后是否隐藏真正的 bug。  
如果没有实际问题，就修改代码消除警告，提升代码整洁度。

10. **添加注释**：  
当你在阅读代码时，可能会遇到令人困惑的部分。  
如果你感到困惑，别人可能也会。  
请在适当位置添加注释并提交补丁，帮助其他人理解代码。

## 编写文档

文档常常是被忽视的一部分。  
而且很多时候文档是“内部人”写给“内部人”的，忽略了初学者视角。  
如果你曾看过某个手册让你觉得：“作者好像默认我已经懂这套系统了”，你就明白我的意思了。  
新人的眼睛能发现老成员早已忽视的问题。

11. **创建示例**：  
任何项目都不嫌示例多。  
无论是 Web API、函数库、图形工具（如 Gimp）或命令行工具，  
一个实用示例往往比一大堆文档更能直观说明使用方式。  
对于 API 或库，可以写个简单的 demo；对于工具，展示真实的使用情景。  
如果你擅长视觉内容，也可以录屏展示如何安装、配置等步骤。

## 参与社区

开源项目不仅仅是代码。社区才是开源的生命力来源。以下是你可以帮助社区的方式：

12. **回答问题**：  
帮助新手是社区成长的重要方式。  
即使对方的问题很基础，也不要敷衍了事。  
哪怕是你很想说“RTFM”，请记住：帮助他们，就等于在培养未来的维护者。  
每个人都是从新手走过来的，项目要保持活力就需要不断有新人加入。

13. **写一篇博客**：  
如果你有博客，请写下你使用该项目的经验。  
记录你遇到的问题和解决办法，这不仅可以帮助搜索到的人，也有助于传播该项目。  
（顺带一提，如果你未来找工作，技术博客是一个很好的展示作品集的方式）

14. **优化网站**：  
如果你有网页设计技能，可以协助美化项目网站或设计 logo，提升项目的公众形象。  
这些往往是开源社区中缺乏的技能，我相信很多维护者都会非常欢迎这方面的协助。

15. **编写技术文档**：  
如果你擅长用通俗易懂的方式说明软件原理，可以帮助项目撰写或更新技术文档。  
很多开源项目都在寻找志愿者来扩展文档，尤其是面向普通大众的部分。  
你不需要是程序员，只要能把话说清楚就行。

最重要的是，倾听周围人的讨论，观察有没有什么急需解决的问题。  
例如，在 Parrot 项目的邮件列表中，有人提议将工单系统从 Trac 转移到 GitHub。  
但由于缺乏转换工具，一度引发争论。我当时提出“我可以写一个转换器”。  
大家非常欢迎这个提议。我花时间写了一个转换程序，把 450 多条工单全部迁移了过去。  
这是一次很成功的贡献。开发者继续专注写代码，而我解决了一个让大家头疼的问题。

16. **教学与协助他人**：  
最好的学习方式就是尝试去教别人。  
能用最简单的例子讲清复杂概念的老师，往往才是最厉害的。  
教学不但能加深你自己的理解，也能帮助别人快速上手。  
你从别人那里学到的知识，也请传递下去，让世界变得更美好。