Eclipse开源政策系列 – 11 – Eclipse项目的社区开发

原文链接：

http://wiki.eclipse.org/Community_Development_for_Eclipse_Projects

 

社区和生态系统的开发这两件事需要每个提交者都花一些时间来进行思考，并且最好能在有空时做点什么。归根到底来说，如果没有这些人和事很难说你的项目能取得成功。从社区和生态系统中你可以获取更多的贡献和其它协助来使你的开源项目走向成功。

本文意在提供一些有用的建议来吸引和维持一个社区。

透明性

所有的同事一起讨论项目计划是一件很棒的事情。为了帮助你的社区了解项目中正在发生的事情，并使他们觉得自己能参与其中，需要使用下面描述的支持渠道进行沟通。可以考虑汇总用户的交流信息，包括在项目邮件列表、项目网站、或者Bugzilla中bug。Bugzilla对于了解这些交流情况特别有效——因为它会促进后续的沟通，并且由于这些沟通往往会转化成项目的功能特性或问题修复——这可能是汇总交流结果的大本营。

项目网站

● 必须有一个清晰并且简洁的项目描述。需要想办法确认项目描述是否确实清晰并且简洁。在项目网站上的描述必须与项目摘要页面上的描述一样。

● 必须包含指向项目摘要页面（Project Summary Page）的链接。

● 必须有一个合理的外观。确保页面（至少）在Firefox和IE中都能被正确地渲染。例如确保页面不要遗漏</div>标签。

● 必须提供一个包含相关信息的“开始启动（Getting Started）”章节，帮助采用者获得和使用项目产物，并且帮助开发者获得代码并配置其工作空间（EGit）项目的贡献者指南（Contributor Guide）是一个非常优秀的例子。

○ 应该包括一个或多个团队项目集（Team Project Sets）或者类似内容以便于有意者能将代码加载到本地工作空间中。

● 必须提供一个帮助链接（例如，链接到论坛或新闻组）

● 应该包含这些链接：文档、博客、新闻组、邮件列表、bug列表以及其它项目的信息源

● 应该包含一个指向项目建议书、计划、IP log等内容的链接

● 应该包含一个简短的项目展示，该展示除了提供类似PDF这种便携式文件格式之外，还需要提供“源文件”的格式（例如PPT或ODP文件）。

● 应该包含“如何向项目提交内容”以及“如何变成一个项目提交者”的信息。至少，其中应该包含一个指向Eclipse开发过程（Eclipse Development Process）的“提交者和贡献者（Contributors and Committers）”章节的链接。

● 可以包含一个重要人员列表（例如提交者和贡献者）

项目摘要页

● 必须有一个清晰且简洁的项目描述

● 应该尽可能多地包含关于项目的信息。在门户上提供尽可能细致的信息以便于有意者可以找到新闻组、邮件列表、项目计划、IP日志等信息。

新闻组、邮件列表、论坛

项目的采用者经常通过新闻组来与项目进行沟通。通常对那些采用者来说这也是唯一真实的支持渠道。每个项目都应该有至少一个提交者监视器eclipse.newcomer（译者注：可以考虑使用https://www.eclipse.org/forums/index.php/f/89/替代）来了解在其中提出的问题以及提升项目的关注度。

当你的社区提出了问题，尽可能快地回答他们。不要让任何问题悬而不决。鼓励所有的项目提交者监视新闻组，或者至少轮流进行监视。当然所有对社区的支持都需要开展很多的工作，并且一些人会发现如果对细枝末节的活动都花上很多时间是一件很难被接受的事情。这样的顾虑完全是一种糟糕的误导，因为这恰恰是取得成功的关键。不要把你的社区晾在那里。

下面是关于如何高效而快速地处理你的新闻组的一个简单流程（感谢Ed Merks）：

● 快速地看一眼，确认是否有谁具有答复该话题所需的技能

● 如果没有，则输入回复。

● 在顶端输入人员的姓名使其变成私人消息；尽量不要有拼写错误，因为这是很不礼貌的。

● 输入“请在下面评论（Comments below）” 。

● 开始阅读并且一旦有想法跳出来就输入它，无论何时何地。

● 在结尾之前尽量使问题得到回答。

● 如果没有得到回答，则继续提出问题，使得提问的人必须先回答你的疑问。

● 砍柴、挑水、重复。

● 避免无限循环。

将答案归纳到FAQ或某种类型的Wiki中是明智的选择。在各种新闻组（尤其是在eclipse.newcomer）中尽可能重复这些过程，因为Eclipse所有取得的成功都会反映到你个人的成功中去。你对高品质服务所作出的奉献和支持是你的生态系统的动力，并且生态系统的成功是用你有限的个人能力创造最大化影响力的最高效途径。

采用者在开发者邮件列表（以及其它“不合适的”论坛，例如私人e-mail）中的提问都应该被礼貌地予以答复。问题（以及未来的问题）都应该在新闻组中提出，这是一个合理化建议，因为这样使其能够被“更广泛的观众所看到，进而更及时地得到答复”。

在你的回复中要避免消极言论、咒骂、贬低或者其它蔑视行为。不是所有的回答都需要来自项目的提交者：授予你的社区在新闻组中回答问题的权利。当社区成员给出的回答需要进一步进行阐明时（他们可能回答得不够完善，或者不是100%地正确），则要有礼貌地进行阐明。

你的社区被经营得越受欢迎，你的项目就越容易取得成功。

Bugzilla

当你的社区报告了一个问题时，要尽快地修复它。要让愿望清单（我希望它更优秀）和真实缺陷清单（它崩溃了，因为并未按设计方式工作）显得不同。对于社区来说，1000条Bugzilla清单更像是1000条缺陷，而不像1000个愿望，这对大家来说很糟糕。对大多数报告不作出响应也是很糟糕的消息。你的社区将会将其理解为缺乏尊重，并且诸如缺乏资源之类的借口对于消除这种负面言论毫无帮助。

在项目代码库中的每次提交都应该带有一个对应的Bugzilla记录。在提交的注释中包含指向该记录的链接，这样查看你的代码历史的人就能根据链接找到与该次提交相关的讨论、或者其它有用的信息。如果对bug的讨论非常有用，则可以考虑在代码注释中直接包含bug序号。这会帮助你的社区和提交者更好地理解为何你的代码是以这种方式实现的，并且给他们一个预置的位置（例如对应 bug记录）来提出更深入的问题。

其它

● 项目计划必须使用标准格式，并且必须包含未来的里程碑

● 必须有一个公开记录在案的结束机制

● 必须对社区的反馈予以包容和响应。由社区贡献的输入和补丁应该被给予足够的考虑；从社区产生的想法应该被整合到项目之中。

● 应该探索和拓展能够提供社区发展机会的论坛（如展会、会议、在线研讨会等）

● 应该具有至少一个架构委员会导师。无论如何项目都应该找到一个导师。

● 应该定期地发布博客。提交者可以使用Bugzilla账户在Eclipse Blogs站点上创建自己的博客（或者分享一个博客），并且可以申请成为PlanetEclipse的一员。

● 应该将Planet Eclipse或其它（可能是特定领域的）博客上的与项目相关的内容汇集起来。

● 应该有代码。

● 应该定期地贡献代码。

● 应该丰富多彩。项目应该尽可能地从社区吸引到更多的提交者。

成功的标志

从根本上来讲，上面提到的所有事情都是希望能够让社区了解你的项目并提供参与项目的机会。提供这样的机会是一码事，而实际上吸引住一个社区又是另外一码事了。

如果你已经取得了下面的成绩（并非是排他性清单）则说明你已经成功了：

● 由非提交者提出了很多bug。

● 非提交者写了关于你的项目的博客。

● 由非提交者开发、提交了很多的文档、介绍、广播、在线研讨会等。

● 项目不再是围绕你一个人而运转。

永远讲信用

要对你的贡献者讲信用。

有部分内容，尤其是关于“新闻组”和“Bugzilla”的部分是从一篇非常优秀的博客： Ed Merks写的 服务与支持：你的生态系统的动力之源（Service and Support: The Fuel for Your Ecosystem）中引用过来。