GitHub 官方推荐的开源指南，新手老手都别错过

正文

请到「今天看啥」查看全文

• 组织关于项目的专题讨论会或聚会，就像 @fzamperin 为 NodeSchool 所做的那样。

• 组织项目会议（如果他们有的话）

• 帮助团体成员找到合适的会议并提交演讲提议

你是否喜欢设计？

• 调整布局以提高项目的可用性

• 做用户调查以重新组织和改善项目的导航和菜单，就像 Drupal 建议的那样。

• 制订风格指南以帮助项目拥有一致的视觉设计

• 为T恤或新的 logo 绘画，就像 hapi.js 的贡献者所做的那样。

你是否喜欢写作？

• 编写和改进项目文档

• 组织一个示例文件夹，展示怎样使用项目

• 开办项目通讯，或从邮件列表中组织重要内容

• 为项目编写教程，就像 pypa 的贡献者所做的那样。

• 翻译项目的文档

说真的，“文档”极其重要。到目前为止，Babel（Kittens 的开源项目）的文档一直很棒，已经成为了它的杀手级特性。但是肯定还需要做一些工作加以完善，甚至加一些段落上去，对此我非常感激。 — @kittens，《需要贡献者》

你是否喜欢组织？

• 链接重复的 Issue，给出新的 Issue 标签建议，让事情井井有条

• 检查开放的 Issue ，提议关闭旧的 Issue ，就像 @nzakas 为 eslint 所做的那样

• 在最近开放的 Issue 中提有助于澄清的问题，把讨论向前推进

你是否喜欢写代码？

• 找一个开放的 Issue 着手处理，就像 @dianjin 为 Leaflet 所做的那样

• 问问你是否能帮忙写一个新特性

• 自动化项目的设置

• 提升工具和测试

你是否喜欢帮助他人？

• 在诸如 Stack Overflow（就像这个 Postgres 的例子一样）或 reddit 之类的地方回答关于项目的问题

• 在开放的 Issue 中为人们回答问题

• 帮忙主持讨论版或会话通道（conversation channels）

你是否喜欢为他人的代码提供帮助？

• 审查他人提交的代码

• 为如何使用项目写教程

• 为其它贡献者提供指导，就像 @ereichert 在 Rust 上为 @bronzdoc 所做的那样

你并不非得要在软件项目中工作！

虽然“开源”通常指软件，但你可以在任何事情上协作。有书籍、食谱、清单和课程是作为开源项目开发的。

例如：

• @sindresorhus 组织了一个 Awesome 的清单列表

• @h5bp 为前端开发求职者维护了一个可能的面试问题的清单

• @stuartlynn 和 @nicole-a-tesla 制作了一份关于 puffins 的有趣事实的集合

即使你是一名软件开发者，在文档项目上的工作也能帮你在开源方面起步。在与代码无关的项目中工作常常不那么令人生畏，而且协作的过程将增强你的自信和经验。

第三部分：熟悉一个新项目

如果你去看一个 Issue 追踪器，发现事情看起来令人困惑，并不是只有你这样。这些工具需要大量的隐性知识，但人们能帮你驾驭它，你也能向他们提问。 — @shaunagm，《怎样为开源做贡献》

对任何超过修正拼写错误的事情来说，为开源做贡献就像在社交聚会上走向一群陌生人。如果当他们正在深入讨论金鱼时，你开始谈论美洲鸵，他们可能有点奇怪地看着你。

在带着你自己的建议盲目投入以前，先从学习怎样观察聚会中的人，参与他们讨论的话题开始。这样做能增加你的想法被注意到和听取的可能性。

开源项目剖析

每个开源团体都是不同的。

在一个开源项目中花了若干年时间意味着你已经了解了一个开源项目。转向一个不同的项目，你可能会发现词汇、规范和沟通方式完全不同。

即便如此，许多开源项目遵循着相似的组织结构。理解不同的团体角色和总体过程将帮你迅速熟悉任何新项目。

一个典型的开源项目有以下几类人：

• 作者（Author）： 创建该项目的人或组织。

• 所有者（Owner）： 对组织或仓库（repository）拥有行政所有权的人（并不总和原始作者是同一个人）

• 维护者（Maintainers）： 对推动愿景和管理项目的组织方面负有责任的贡献者。（他们可能也是项目的作者或所有者）

请到「今天看啥」查看全文