作社区主导项目的基本工具

 
对于建设和管理由开源社区主导的项目，我们并没有一种唯一正确的方法，但一些常用工具和实践可以帮助我们完成这项工作。关键问题是使用适合您社区的工具，并保持工具数量最小。本文档总结了大多数开源项目常用的工具，并推荐了使用这些工具建设社区的几种方法。

工具应该作为辅助，而非主导

很多人认为，将项目开源就是要花大量时间告诉别人自己在做什么。但事实未必如此。如果您认真选择了工具以及要使用这些工具的开发流程，那么您需要做的对外交流工作将只是伴随开发过程的小插曲而已。

要理解这一事实，我们首先应该理解，开源的目标不是确保所有人都明白开发过程的每个特定时间点都发生了什么。开源的目标应该是，确保有足够兴趣的人 能找到他们需要的信息。我们只需关注那些有足够兴趣并能完成自己那部分工作的人，我们可以节省社区现有成员辅导新成员所需的时间。这样，现有成员就能更专 注于寻找自己想要的结果。这似乎有悖于创建社区的初衷，因此让我们先把这问题放一放。

人们参与社区主导的项目是为了满足自己的需要——可称为“搔痒”。个人成员的初衷可能不是创建社区，而是解决工作、研究或业余消遣中的某个实际问题。因此，运作此类项目时，流程和社区方面的工作不应影响参与者的兴趣。

尽管如此，一个运作良好的开源项目还是会使用一套简单的流程和工具，以便在向参与者知会项目进展和帮助他们“搔自己的痒”之间巧妙平衡。下一节将介绍这些流程和工具。

基础知识

很多不熟悉开源的人错误地认为，自己应该提供尽可能多的工具，以便感兴趣的人以适合自己的方式参与。但这种想法通常是错的。工具应该在有明确需求时才引入。过早引入工具会让用户感到困惑（‘做 X 时应该用哪个工具呢？’），而使用多种工具可能引起混乱，造成事倍功半。

每个开源项目需要四种基本工具和多种非基本工具。所有项目都需要的核心工具包括（且仅限于）：

• 网站：用于在任何特定时间点交流项目的目的和状态。
• 开发者邮件列表：用于随时交流想法、设计和信息。
• 版本控制：用于代码管理和在评审前交流代码更改。
• 问题跟踪器：用于规划、交流工作计划和当前活动。

使用这些工具时，典型的核心开发流程如下：

• 在问题跟踪器中记录要处理的问题（bug、新功能、增强功能等）。
• 将问题分配给开发者。
• [可选]对于复杂的或会引起重大更改的工作，将工作的目的发布至开发者邮件列表（通常在问题跟踪器更新时自动生成邮件）
• 着手开发工作（如有必要，通过邮件列表参与到更广泛的开发社区中）
• [如果是提交者]早期提交，通常提交至版本控制系统；系统自动向开发者邮件列表发送消息，允许评审代码，必要时允许请求更改代码。
• [如果不是提交者]频繁向问题跟踪器提交补丁或拉取请求；系统自动向开发者邮件列表发送消息，允许评审补丁，必要时允许请求更改补丁。
• 重复以上步骤，直至工作完成且达到所有评审要求。
• 将问题标记为完成（系统向开发者邮件列表发送消息）。
• 适时更新网站。

关于此流程，重要的一点是，开发者无需大量投入即可向社区知会开发工作进展。他们要做的工作与在运作良好的软件项目中的工作是一样的，没有任何额外工作。大部分社区更新是由工具自动创建的，无需人为干预。因此，实现开放沟通只需在一开始正确安装工具，仅此而已。

现在，我们了解了基本工具以及它们在开发流程中的作用，下面将详细介绍每一种工具。我们还会介绍您的项目在进展到一定阶段后可能采用的其它工具的优缺点。

沟通工具

沟通是开源项目成功的关键。沟通有两种形式：发布和讨论。前者的目的是向别人传达信息；后者的目的是让别人分享想法和经验。本节将讨论这两种方式。

制订沟通策略时，我们应该记住，用户和贡献者在同一时间出现在同一场合的几率很小，甚至为零。所以，我们有必要建立沟通的基础架构，允许人们在他们喜欢的时间、以他们喜欢的方式参与到项目中。这一基础架构是整个项目的基石。如果架构没有搭好，项目参与者将无法协作。

在开源项目中，邮件列表是双向沟通的唯一必要机制，但不同的项目会使用很多其它机制。本节讨论为什么邮件列表是基本机制，以及为什么其它机制可能与项目核心活动略有偏差。

邮件列表

邮件列表用于讨论、取得共识、分享信息以及公共认可。邮件列表记录项目开发路径，提供针对不熟悉项目的人的说明与支持的书面记录。邮件列表可能是最重要的社区开发工具。

邮件列表已成为大多数开源软件开发者惯用的工具。邮件客户端是他们在一天中最先打开并反复使用的应用。邮件列表提供强大的功能，可高效过滤和管理邮件，并允许任何设备在线或离线访问邮件。简单地说，电子邮件是开源开发者工作的中心。

有些人认为，基于 Web 的论坛因其“拉取”机制（即要求用户访问在线论坛以获取最新帖子）而优于电子邮件。他们称，不是所有人都能处理大量电子邮件，大多数人不希望无孔不入的电 子邮件发送到他们的收件箱。当然，这种观点很有道理。但关键是“大多数”这个词。创建新项目时，我们应该考虑我们想吸引什么样的人。新项目需要新的贡献 者，而不需要、而且很可能无法服务新用户。我们需要开发者，所以我们可能去关注技术人员，而他们的日常工作可能已经在围绕电子邮件客户端进行了。对于这些 人来说，电子邮件是更有效、更高效的工具。

这并不是说，开源项目完全不会使用在线论坛。在下一节中，我们会讨论在线论坛适用的场景。但关键问题仍然是，在大多数情况下，邮件列表更适用于开发者社区。此外，后续章节会谈到，邮件列表更易与项目所需的其它基本工具集成。

我们已经讨论了为什么邮件列表比论坛更适用于开发者社区；但很多新的邮件列表工具同时提供基于 Web 的接口和电子邮件客户端接口，以便用户选择最符合自己需要的机制。如果您还在为社区选择邮件列表而非论坛犹豫不决，我们强烈建议您选择以下一种混合工具。

存档邮件

如果能够正确使用邮件列表，那么开源开发项目的存档邮件将成为该项目最有价值的资源之一。存档邮件记录了设计讨论和决定、操作说明信息、使用案例以及需求分析等大量有价值的信息。

所有项目都应提供邮件列表的可搜索存档，如有可能，还应尽量引用这些备份，而非重复回答某个问题或重新作出某个决定，以避免不必要的重复劳动。与联 合源类似，存档设置不应增加项目组的工作量。大多数邮件列表提供商同时提供存档解决方案。如果您的邮件列表提供商未提供存档解决方案，您还可以在大量免费 的在线公共邮件列表存档工具中进行选择。

论坛

论坛的优点在于易于使用。并非只有电子邮件高级用户才能最大限度地利用论坛。与邮件列表相比，论坛的一大优势在于，可以在讨论界面中提供可搜索存档。论坛与邮件列表相比的弱点在于，不支持离线访问、过滤、互操作性等高级功能。

虽然，对于技术人员来说，邮件列表是最佳沟通工具，但人们常常认为，不熟悉技术的用户需要其它沟通机制。事实并不总是这样；工具的选择取决于项目的性质。但如果您的用户不懂技术，能够提供用户支持的论坛可能是更好的选择。

虽然论坛可能适合于用户，但在创建论坛（或针对用户的独立邮件列表）前，您仍需认真考虑。您的项目已经发展到能够吸引大量用户的程度了吗？您有足够的开发者来监控和响应论坛中的用户问询吗？

过早创建论坛或针对用户的邮件列表，可能迫使用户进入封闭的‘黑暗房间’，让他们不知道是否有人在‘听’他们讲话。只有当第一沟通渠道的负荷大到有必要分流时，我们才应该创建第二沟通渠道。

问答

近年来，由 Stack Overflow 倡导的用户管理的问答站点发展迅速。此类站点（通常称为 Stack Exchange，以为其提供托管的最流行的托管软件 Stack Exchange 而得名）非常适合各种水平的用户提出和回答问题。社区会投票支持或否决答案，也就是说，被评为“已接受”的答案会直接显示在问题下面，而不实用的答案将被 隐藏。站点可作为有用的辅助渠道，避免技术讨论渠道充斥大量的重复问题。提出问题意味着，寻求支持的用户可以直接找到答案，而不必查阅大量论坛帖子。

博客

博客非常适合传播想法或新闻，但不适于活跃的讨论。博客通常提供评论功能，但一般不提供完整的对话支持功能。与论坛类似，博客要求用户必须访问站 点，才能参与互动。因此，并非所有人都能看到后续评论。也因此，博客不应被视为辅助讨论工具。相反，博客可作为对项目相关问题进行发布和详细说明的工具。 博客或播客还允许参与者展示其在开发和支持“工作”环境以外的个性化信息，藉此来构建社区关系。

联合

联合指以机器可读形式分享信息，以便于第三方方便地引用您项目中的相关内容。广泛使用的联合格式（如 RSS、ATOM 馈送）允许他人轻松地从您的项目中抽取内容并进行整合，以用于他们的工作或社区。就是说，联合源可以有多种形式，如用户的邮件客户端、源阅读程序、基于 Web 的聚合器或网站。向尽可能多的沟通渠道提供联合访问权限可以增加吸引新用户的机会。

联合内容本身并非沟通工具，它仅提供对预先存在内容的访问权限。通过慎重选择适当的核心工具，您可确保自动提供联合源。就是说，您应设法选择能够自动提供适当数据联合源的网站工具以及沟通、问题跟踪和版本控制工具。

社交网络和微博

社交网络常常被视为社区建设的主要部分。然而，社交网络对开源项目的价值并不明确。主要问题是，大多数社交网络就象带有围墙的花园，一旦选择了某个社交网络，潜在的贡献者就只能使用这个站点，即使这不是他们的首选站点。

这可能便于将您的内容联合到社交网站中。这种做法适用于部分项目，但将社区划分为官方渠道和社交网络渠道时一定要慎重。

网站

网站是发布各种形式信息的机制。网站用于提供项目基本信息以及连接项目其它部分的门户。开源项目的网站与其它网站并无不同。SourceForge 或 GitHub 等很多代码托管平台提供简单网站托管服务，但您可能希望托管自己的网站。使用内容管理系统可轻松确保您的网站得到持续更新，并允许项目其他成员管理站点。

截屏视频

截屏视频是展示软件使用情况的视频。用户无需安装软件即可查看该软件的截屏视频。截屏视频有助于吸引新用户及提供部分系统文档。但随着产品界面的成熟及新功能的推出，截屏视频会很快过时。维护截屏视频的成本较高，这可能也会限制截屏视频的广泛应用。

对于通过 Web 浏览器访问的应用程序，可使用自动浏览器测试技术来确保无 bug 的用户体验。在每次版本发布前的准备过程中，可低速运行这些自动测试功能，并以截屏视频形式进行记录。 每个版本都需要充分测试，而且测试必须与接口和功能更新同步进行，这就提供了一种半自动的截屏视频记录方式。

版本控制系统

版本控制系统（VCS，也称为修订版本控制系统，即 RCS）对管理项目资源非常重要。通过版本控制系统，您可以跟踪版本更改人、更改内容、更改时间和更改原因，必要时还可以回滚引发问题的更改。使用版本控 制系统很简单，而正确使用却不那么简单。如果您从未使用过版本控制系统，建议您阅读我们的版本控制文档。

版本控制系统有两种模式 – 集中式和分布式。想一想哪种模式更适合您的项目管理和工作流程需求。您选择不同的版本控制系统模式，可用的代码托管站点可能也不同，因为每个站点仅支持几种特定的版本控制系统。

如果您正确使用了版本控制系统，那么该系统可及时向开发者发送通知，简化版本管理，记录 bug 工作项，简化实验过程，管理对版本的贡献，并控制对资源的写权限。版本控制系统是一种协调和管理工具，也是您项目的时间机器。版本控制系统可确保将所有资 源更新通知所有成员，并允许任何人检索项目周期中任一指定时间点的全部资源。

为有效使用版本控制系统，所有贡献者必须遵循‘早提交，多提交’准则。对于测试运行后的开发者而言，做到这一点很容易：只需在通过每项新测试后提 交。提交后，系统将发送实现步骤完成通知，问题跟踪器自动记录针对问题的提交。这样，其他开发者就可以查看所做的更改，避免重复劳动。

问题跟踪/项目管理

通过问题跟踪器，您的用户可以报告 bug 并请求提供新功能。您的项目管理团队也可以使用问题跟踪器来制订工作计划，并优先处理社区推动的请求。

使用问题跟踪器，您可以清楚地向用户说明，您未来的代码版本提供哪些值得期待的新功能。这意味着，如果用户需要某项功能，或要求修复某个 bug，而您在近期内不打算实现此功能或修复，那么用户可以选择自行投入资源来开发此功能或修复此 bug。清楚、高效地将您的计划传达给用户，这是吸引用户参与您的开发项目的第一步。

问题跟踪器最大的用途可能就是，记录项目新成员为熟悉项目而需要解决的问题。简单的问题或有导师提供指导的问题都属于此类问题。当有新成员加入时，现有社区成员应关注此类问题。

知识产权 (IPR) 管理

您应该知道您的项目的版权归属，这一点很重要。为做到这一点，您必须能够追溯所有贡献的原作者。对于直接影响您的项目输出的贡献（如程序代码或文档），其版权可通过版本控制系统（如上所述）以及明确定义的贡献者许可协议和问题跟踪器记录的提交过程实现高效管理。

对于源代码或文档以外的非直接贡献（如设计思路），应以公开、可追溯的方式获得，这一点很重要。如果您通过邮件列表进行设计讨论，那么此邮件列表的存档则是追溯贡献的最佳方式。

对于软件代码形式的贡献，版本控制系统和问题跟踪器可记录贡献过程。补丁提交至问题跟踪器后，开发者会选取并审阅。当补丁可应用于基本代码中时，版本控制系统将自动记录向问题跟踪器‘提交’的补丁。

从许多方面来说，开源项目的知识产权管理是最重要也是最繁琐的工作。知识产权管理并不会直接增强 软件功能，而且初看起来是一项费时、又需要流程驱动的工作。但如果您仔细设置了项目资源，大部分流程将自动完成，并对大多数开发者透明。这样的流程会帮助 您软件的潜在用户建立信心，而更多用户就意味着更多贡献者。

综述

为您的项目选择正确的工具可以简化项目本身的管理，无论您是否吸引了社区的参与。而拥有工具只是一个开始，您还必须以一致的、设想的方式使用工具。如果您一开始就使用了正确的工具，那么您将避免很多麻烦，并能为在适当的时间围绕您的项目创建社区创造最佳条件。

来源:Ross Gardler作者:开源社编译