开源项目中的沟通规范#

尽管项目使用的沟通工具不断演进，但项目参与者之间的最佳沟通实践却鲜少改变。本章将涵盖项目沟通的基本要点，并就如何通过善用特定工具与平台服务全球受众提供建议。我们将看到，无论项目选择何种沟通工具或平台，那些维系社区高效沟通的规范与技巧在任何地方都同样适用。最后，我们将探讨开源项目中不断变化的工具与沟通实践如何给外部观察者（尤其是学术研究者）带来挑战，并提出缓解这些挑战的建议，以惠及所有项目参与者。

自由和开源软件项目中沟通平台的演进#

随着自由开源软件项目数量的增长，项目使用的沟通工具——无论是连接用户还是协调开发者与贡献者——都经历了演变。互联网中继聊天（IRC）曾是实时项目交流的首选方案，许多大型项目仅通过邮件列表进行开发讨论。Freshmeat曾是了解新项目发布或现有项目更新的主要平台，而功能设计和项目改进的讨论则通过电子邮件展开，并归档在项目的邮件列表存档中。

如今，这一格局已发生多方面的转变。

尽管实时聊天在当前或许不如往日普遍，但项目并未完全放弃这种形式。许多项目转而采用被认为更友好或更易接入的服务，例如 Matrix、Slack、RocketChat 等。有些项目甚至会使用桥接工具兼容旧版聊天系统（如 IRC），以帮助社区逐步过渡到包含新型服务的生态中。

部分社区仍采用电子邮件进行异步沟通，而另一些社区则发现通过提供在线论坛协作机会能取得更好效果——这种形式对许多开发者而言更为熟悉，他们最初编程时恰逢 Reddit 和 Imgur 等新兴热门论坛兴起，习惯于在此类平台分享资讯与观点。论坛支持者认为其视觉布局更具吸引力，管理员也偏好该媒介精细的权限控制功能，这些功能使内容管理更为便捷（例如在激烈讨论中暂停特定主题下的所有发帖，通过多数论坛软件即可轻松实现——邮件列表则难以做到这点）。

虽然像Freshcode等网站延续了早期精神，自由开源软件项目也广泛利用 X 和 Facebook 等社交媒体服务与用户及开发者群体互动。社交媒体是项目推广的绝佳渠道，能帮助受众及时了解重大项目进展。

社交媒体还具备以下功能：

宣传即将举行的活动
内容或演讲的直播
激发对项目的兴趣
超越项目简报、网站或博客范围的其他营销与推广形式
许多用户现在期望通过这些平台获得基础技术支持

虽然邮件列表存档可能不再作为项目讨论的权威记录，但 GitHub 作为在线开发和协作平台的流行，意味着许多项目现在通过 GitHub issues 来管理开发讨论。GitHub issues 可以使用标签进行区分，例如区分关于新功能实现的讨论和报告软件未按预期工作的讨论。

然而，尽管自由开源项目用于实现沟通的工具在快速发展，人类对信息和连接感的需求却始终未变。

项目沟通：基础篇#

卓越沟通的成就#

人们必须理解与开源软件社区合作的"对象"、"内容"、"地点"、"时间"、"原因"及"方式"。经过深思熟虑建立并妥善维护的沟通渠道，能使开源项目及其参与者实现以下目标：

建立对软件本身的共识理解——包括软件是什么、人们为何要使用它，以及如何上手使用。
向社区传授如何使用该软件以及如何为项目做出贡献。
及时向成员通报项目动态（如会议、网络研讨会等）和最新进展（如新增软件功能、工作组成立或新贡献者加入）。
记录并传承项目决策规范与实践经验。
允许用户报告开源项目软件本身的错误，并提交针对他们或他人发现错误的修复方案。
在参与者中培养共同的兴趣和目标意识，并为项目成员提供在线社交或“聚会”的渠道。
为项目贡献者提供一个协作空间，无论是编写项目文档还是讨论代码库特定部分的重构方案。

了解你的受众#

在编写项目文档和其他信息资源时，需认识到这些内容面向多个不同的受众群体。了解这些受众并优先考虑他们的独特需求，有助于你创作出更优质的材料。

例如，考虑项目_用户_和项目_开发者_之间的基本区别。想_使用_软件感兴趣的人会关心如何安装、如何配置以及完成手头任务（如搭建网站）所需了解的内容。开发者同样会关注这些细节，但如果要有效参与项目贡献，他们还需要更多详细信息。

如果项目遵循特定的编码规范，请务必在开发者文档中明确说明这些规范。因为代码缩进方式不合要求而被维护者拒绝补丁，可能会大大打击贡献者的积极性。但对于用户来说，这些技术细节通常并不必要。

{% hint style="success" %} 为项目制定风格指南，并确保在面向开发者的文档中易于查找。并非所有项目都需要创建自己的风格指南，但注明项目将遵循的代码规范是最佳实践。如果项目采用已发布的风格指南，务必在开发者文档[1]中提供其链接。 {% endhint %}

虚拟展示：精心打造项目网站#

当人们寻找可能帮助他们解决问题的软件信息时，他们的第一站很可能是项目网站。

项目网站无需复杂设计也能发挥作用（尽管更美观的站点有助于项目推广）。GitHub 上详尽的README.md文件完全可以充当项目网站，只要其提供的信息能让用户和潜在贡献者对项目有充分了解。基础项目网站至少应包含以下部分。

项目概述#

在项目网站的显眼位置简要概述项目内容。项目描述应包含代码库的设计用途以及使用者可能解决的问题。确保这些信息简洁明了且易于查找至关重要。在项目主页发布简短说明，让感兴趣的人能立即判断该项目是否符合其需求。

请将这段信息视为向从未听说过你项目的人解释它为何重要的机会——用 30 秒或更短时间。例如，Drupal 的简介页面是这样描述该项目的：

Drupal 是内容管理软件。你日常使用的许多网站和应用程序都由它构建而成。Drupal 具备出色的标准功能，例如便捷的内容创作、可靠的性能以及卓越的安全性。但使其与众不同的是其灵活性——模块化设计正是其核心理念之一。其工具能帮助你构建动态网络体验所需的多样化、结构化内容。

在这段简短的描述中，我们了解到：

Drupal 是什么（一种内容管理系统）。
什么是内容管理系统（用于构建网站的工具）。
为什么 Drupal 是一个引人注目的选择（易于使用、可靠、安全且灵活）。

让我们再看一个流行项目的例子：Kubernetes。

当访问项目主页kubernetes.io时，访客立即看到以下说明：

Kubernetes（K8s）是一个用于自动化部署、扩展和管理容器化应用程序的开源系统。它将构成应用程序的容器分组为逻辑单元，便于管理和发现。Kubernetes 基于 Google 15 年生产环境工作负载的运行经验，并结合了来自社区的最佳创意和实践。

在这个描述中，我们可以立即了解到：

Kubernetes 是什么。（它是一个用于管理容器化应用程序的系统，涵盖部署、扩展和管理功能。）
Kubernetes 的缩写规则。（这类细节能迅速提升新成员的熟悉度——没有人会被要求事先掌握晦涩的缩写。）
Kubernetes 的诞生地。（谷歌被标注为该代码库的创始者，表明该项目专注于企业级应用，并确保软件设计精良且维护良好。）
Kubernetes 是开源的。（用户可以自由使用、运行、修改及共享代码变更；任何关于许可费用、采购流程等准入门槛的疑虑都不复存在。）
本项目重视社区参与。（可以预期，代码、文档等贡献是受欢迎且受鼓励的。）

快速入门#

编写优秀"入门"文档（有时称为"上手文档"）的流程不在本章讨论范围内。（详见本指南专设的"新手指引"章节。）此处只需明确：开源项目网站应设立专门板块，帮助新用户和潜在贡献者开始使用软件。将该板块清晰标注为"入门指南"或"新用户"能让人在需要时轻松找到。若能在新手指引文档中进一步区分"新用户"与"新贡献者"则更为理想，因为这两个群体的需求差异显著。在项目网站上为新人明确指引这些资源，有助于避免论坛和实时聊天室等沟通渠道反复出现"如何上手"的重复提问。

{% hint style="success" %} 在项目的新手入门指南中，为初次接触项目的用户和参与者提供所有能获取帮助的渠道信息。例如：可以设置名为"新手区"的 Slack 频道，由乐于指导新人上手的成员提供支持；而持续性的开发讨论则可在"开发者"频道进行。 {% endhint %}

常见问题#

展示项目基本信息的另一绝佳位置是常见问题解答（FAQ）页面。若项目开发尚处初期阶段，只需准备基础 FAQ，说明项目内容、代码库用途以及如何获取代码即可。但随着更多参与者加入——包括新用户、开发人员、文档编写者等——你可能会发现自己反复回答相同的基础问题。（在这个过程中，你还会发现项目的许多方面对新人而言并不像你认为的那样显而易见。）这些重复性问题正是完善文档和向社区寻求帮助的良机。

保持 FAQ 内容更新且易于查找。但更好的做法是：邀请社区成员协助完善它。无论是通过项目邮件列表回复邮件，还是在实时聊天中解答新人的疑问时，都可以请提问者将问题与答案整理成文，纳入项目 FAQ。通过向社区寻求帮助，你能实现多重效果：

协助你保持文档内容的相关性和时效性。
展现对社区贡献的欢迎与鼓励。
主动邀请已表现出项目兴趣的人进一步参与，寻求他们的帮助。

理想情况下，新手应能自行编辑 FAQ 文档。在请求对方贡献 FAQ 内容时，附上编辑指南可显著降低参与门槛，从而提高贡献接收率。若项目设有贡献者名单，务必将 FAQ 贡献者列入其中。人们乐于看到自己的劳动成果（无论多微小）获得认可。这种认可能赋予贡献者归属感与项目忠诚度。当人们感到自己的付出受到重视，便更可能长期留存，通过提交问题或开发新功能等方式持续为项目贡献力量。

记录项目目标和非目标#

项目网站应当清晰阐明该项目的宗旨及核心活动内容。若访客不了解当前进行中的工作与未来规划，将难以找准自身在社区中的定位，也无法明确可以贡献哪些力量。

项目路线图是传达这些目标的常用工具。即便当前资源不足以制定完整路线图，仍需设法让用户和潜在贡献者了解项目全貌。例如，通过简短的博客或论坛帖子发布每周项目进展回顾及未来周/月计划就是个良好开端。这类内容既能帮助新人快速熟悉项目，也可作为意向参与者入门引导的优质参考资料。

阐明项目的非目标同样重要。由于开源项目充满活力的特性，自然会有人发现项目创建者未曾设想的用途，并希望扩展项目功能以满足特定用例。如果项目维护者无意扩大项目现有范围，提前告知潜在贡献者这一立场，将为所有人节省时间和避免失望。在这个轻松分叉的时代，那些只想使用项目部分功能的人可以相对容易地开发和维护更符合自身需求的代码库——完全无需要求原项目维护者偏离既定愿景和已规划的项目范畴。

对于商业导向的项目而言，记录非目标同样至关重要。当贡献者希望以开源方式开发某项功能时，这可能与厂商开发专有特性的目标产生冲突。贡献者仍可选择以开源形式实现该功能，但他们应当从一开始就知晓上游维护者无意将其成果纳入项目代码库。有些人得知厂商正在开发该功能后，可能选择放弃实现；另一些人若知晓该功能不会被纳入项目主干源代码树，也可能选择放弃——因为他们不愿独自承担持续的维护负担。当然，也有人会继续开发符合自身需求的解决方案，并以开源形式发布，无论该功能最终是否被纳入项目的主源码库。

最重要的是，不要让任何人对项目的发展方向感到_意外_。虽然项目不必接受所有贡献，但如果贡献者投入时间和精力开发的内容因与未知路线图（商业或其他方面）冲突而被拒绝，这会在社区中制造紧张气氛，并导致项目维护者失去信任。甚至可能促使人们转而采用该供应商产品的开源替代方案。

未按预期运行：充分利用问题跟踪器#

本节详细介绍了如何将问题追踪器作为核心沟通工具使用。

什么是问题跟踪器？#

问题跟踪器（issue tracker）（有时也称为_错误跟踪器_、问题列表_或_问题队列）是一种工具，当用户认为软件运行不符合预期[2]时，可通过该工具提交问题报告。作为一种监控待办事项并支持对进行中的工作展开协作评论与审查的方式，部分项目会通过问题追踪器来管理整个开发流程。

本节将讨论如何使用问题追踪器来报告软件故障。通过项目的问题追踪器提交问题，你可以确保负责维护的人员看到你的报告并采取相应措施。

为什么要提交问题？#

虽然提交问题可能比在实时聊天中直接求助更繁琐，但这样做有几点重要原因：

项目贡献者无法追踪所有跨平台对话，但他们始终可以参考问题跟踪器来改进项目。

实时聊天和社交媒体是即时性沟通渠道。问题追踪器则是专为记录和审查软件问题而构建的工具。软件项目通常通过将问题追踪器作为核心组件（甚至可能是唯一工具）来定义其近期工作计划，从而对所有待处理事项进行优先级排序。（简而言之，项目的问题追踪器往往等同于项目的待办事项清单。）如果你的问题未被录入问题追踪器，它很可能因忙碌者遗忘细节而无法得到解决。正因如此，当你寻求帮助时，往往会首先被要求提交问题报告，以便项目维护者能够持续跟踪该问题。

提交问题能让你与项目贡献者就问题进行异步沟通，因为各方都可以随时查阅问题描述及后续评论。

当你发现软件存在问题时，可能会意识到该问题实际上是_另一个_问题的根本原因，或者存在_多个_问题相互关联的情况。问题追踪软件允许项目开发者将相关问题归类，这有助于诊断问题的根源。

用户在使用软件时常常会遇到相同的问题，其中许多人会向项目提交问题报告。对于项目维护者来说，处理大量重复问题的报告会耗费大量时间，因为他们需要对每位报告者分别反馈处理进展。幸运的是，问题追踪系统能有效简化这一流程——维护者可以快速关闭重复问题（注明该问题与现有问题重复），并指引问题报告者前往"原始"报告跟进处理进度。

项目维护者随后可在一处向所有遇到该问题的人员进行广播式沟通，既简化了工作流程，又能为所有需要帮助的人提供支持。

确保问题追踪器易于查找#

确保在项目的常见问题解答（FAQ）、使用文档和开发文档中显著显示问题追踪器的位置。如果用户无法确定在哪里提交问题，他们会向项目人员询问。对于这类基础问题反复提供答案来支持热心用户可能会相当耗时。

为你的社区和自己行个方便，让问题追踪系统一目了然。

使用问题模板#

并非所有使用你软件的人都熟悉你社区提交有效错误报告的惯例。为了节省你和错误报告者的时间，提供一个问题模板以确保你获得重现所报告错误及有效分类所需的信息。例如，你可能需要了解错误发生时使用的软件版本或操作系统。如果需要重现错误的常见信息，请在问题模板中要求提供这些内容。

问题模板中的常见字段包括问题摘要、重现步骤、用户观察到的实际行为、软件的预期行为，以及请求提供日志文件或截图以帮助问题审核者更好地理解错误报告。多个问题追踪系统支持错误报告模板，包括 GitHub、GitLab、Redmine和Trac。

如果你发现自己针对不同的错误报告反复询问相同的信息，那么恭喜你。你已经发现了模板中需要改进的部分。

寻求帮助：标记问题以提高清晰度并鼓励贡献#

现代大多数问题跟踪系统都允许用户为提交的问题添加标签，这有助于项目工作的组织管理。通过区分不同类型的请求——如开发新功能、软件缺陷等——项目维护者能够更有条理地处理问题，提高分类效率。此外，许多有意参与开源软件项目的贡献者会通过查看问题列表来寻找适合自己参与的任务，从而更好地理解项目的开发机制。若计划在问题跟踪系统中积极使用标签，请务必在开发文档中明确标注各标签的定义，以确保标签使用的一致性（或仅限项目维护者添加问题标签）。一套使用混乱的标签体系，其作用与未分类的问题列表并无二致。

将问题标记为“新手友好”或“寻求帮助”可以让项目维护者特别标注出适合新加入贡献者处理的问题。这种标记方式表明项目已准备好接纳新贡献者，且维护者欢迎社区在特定领域提供协助。不要害怕针对项目文档、网站或任何你认为有问题的地方提交问题。如果存在当前或潜在贡献者可以帮助改进项目的地方，就在问题跟踪器中提交这些问题，并贴上清晰的标签，让他们知道自己可以参与贡献。

只需_明确_说明（可以在“需要帮助”的问题文本中或通过链接到其他项目文档）你希望他人在处理此类问题时如何参与项目。（Apache Subversion问题页面就是一个很好的例子，它在用户提交问题前就清晰地阐明了需求。）最好鼓励处理这些问题的贡献者在过程中与项目维护者保持沟通，这样他们的贡献更有可能被项目采纳。没有什么比贡献者带着现成的解决方案出现，却被告知他们的具体实现不符合项目需求更能打击热情的了。

清晰友善地沟通#

无论你是报告问题的项目使用者，还是审查拉取请求的项目维护者，_清晰友善地_沟通问题始终至关重要。当工具无法正常工作时，使用者可能会感到沮丧。同样，将项目开发作为业余爱好的人，也不太可能对要求他们花时间解决与自己无关的问题作出积极回应。请记住在与项目其他参与者讨论时保持礼貌和感激，因为每个分享知识的人都在为项目的整体健康发展贡献力量。

当问题成为激烈辩论的焦点#

有时，解决特定问题的细节可能会在社区内引发紧张或争论。

在任何蓬勃发展的项目中——无论是软件还是其他领域——健康且相互尊重的辩论都是不可或缺的一部分，但情绪很容易升温，而且正如大量记录所显示的人们在网络上的行为往往不如面对面时那么文明。

若某个问题引发激烈争议且讨论变得粗鲁或煽动性，可限制该问题的访问权限一段时间（例如 24 至 48 小时），让人们有时间冷静思考，以更平和、建设性的方式阐述观点。

提交问题的快速提示#

感谢那些投入时间和精力开发软件的人们，特别是当你刚接触这个项目时。这些利用（业余）时间为你创造免费开源软件的个体，同样渴望知道自己的时间被珍视、劳动成果被认可。

尽可能详细地提供你遇到的错误信息。如果项目使用了问题模板，请尽可能完整地填写模板内容。

若你无法提供所需信息或不确定如何自行获取，只需注明你已尝试过哪些方法。这些细节有助于维护者判断他们需要采取哪些措施来协助你。

如果项目没有使用问题（issue）模板，可以查看其他已"关闭-已修复"的问题或已合并的拉取请求，了解他人是如何提交错误报告的。若该问题已被修复，那么这些历史记录很可能就能作为重现错误所需信息类型的范例。按照这些报告中的内容进行复现，并尽可能补充更多细节。

快速响应问题的技巧#

“虽然开发社区的规模和技能限制了问题单的处理速度，但项目至少应在问题单出现时立即予以确认。即使问题单会滞留一段时间，及时回应也能鼓励提交者保持参与，因为她能感受到自己的付出已被人工记录（请记住，提交问题单通常比发送电子邮件需要更多精力）。”

— Karl Fogel, Producing Open Source Software[3]

感谢提交者提出问题。帮助项目改进是对项目健康的卓越贡献。此外，通过保持亲切、友善和热情的态度，你将鼓励问题报告者持续参与和贡献。

当以“不予修复”关闭问题时，需说明不予修复的原因。维护者无需被迫接受每一个拉取请求或修复所有报告的问题，但至少应告知问题提交者_为何_某些问题不会被处理。

特别是当有人提交了问题报告及修复代码或新功能实现时，务必向其说明为何其工作成果未被项目采纳。若不作解释，贡献者会感到自己的时间被浪费，进而将精力转向其他软件项目。理想情况下，你应当附上已发布的项目路线图链接，阐明该提交为何不符合项目需求。（参见上文说明。）

对于新贡献者提交的内容，你可以自行修复补丁中的小问题，并附上说明解释修复内容和原因。因细微瑕疵而拒绝补丁会打击贡献积极性，且解释拒绝原因所花的时间往往与进行微小修复相当。这类解释是引导贡献者查阅项目其他资源（如代码风格指南、沟通规范文档等）的绝佳时机。

对于响应"求助"问题提交的内容，需尽早且频繁地与表示有兴趣处理该问题的人员进行沟通。这样做能确保贡献者的提交真正符合项目需求。此外，通过保持对新贡献者的可及性和定期对话，你将与他们建立一种促进相互学习的关系，并增加他们持续参与项目后续工作的可能性。

在问题跟踪系统中进行开发讨论和其他对话#

开源软件开发早期的传统观点认为，社区_不应_在项目的问题跟踪器中进行开发相关讨论。项目社区更倾向于通过邮件列表或论坛开展此类对话，原因包括：

订阅邮件列表的人员无需解析问题跟踪器内容即可发表评论并表达观点和需求
论坛或邮件列表对话被认为更适合异步和长篇交流，而 1990 年代至 2000 年代初流行的问题跟踪工具并不适合开展实质性讨论
要查明某项技术决策的具体原因十分困难，因为这些细节往往埋没在问题追踪系统中，尤其当决策完成后相关问题会被标记为"已关闭"状态。在已关闭的问题中寻找项目技术方向的解释，这种操作方式本身就违背常理。

随着 GitHub 作为一站式在线开发平台的兴起，项目问题追踪器中的讨论已成为主流。GitHub 的问题系统在视觉上复现了论坛软件常见的界面形态，这让在其系统中进行的讨论对成长于网络论坛兴起时代的开发者而言显得尤为自然。此外，当所有基础设施都能通过单一工具管理时，维护 Mailman 实例或额外论坛软件所需的时间和资源就变得冗余。新增功能如对问题"+1"表态、设置特定问题的精细化通知控制、以及锁定问题仅允许项目维护者编辑（同时保持他人可见）等特性，使得转向问题追踪器进行讨论的方案更易被接受且高效。

然而，项目外部人士也应能跟进讨论内容。只有极少数深度投入的参与者会严格追踪每个问题更新，这使得临时贡献者难以参与项目。虽然在线问题追踪系统强大的搜索功能让查找已关闭问题更为便捷，但问题讨论的流程并不能替代对具体实施方案的叙述性说明，或对某项决策原因的阐释。还需注意的是，那些对项目最为熟悉（能轻易回忆起特定讨论对应问题编号）的维护者们，并非总能随时协助项目工作。

以易于访问的方式保存有关决策的知识：

为致力于探究项目流程背后原因的人们节省时间。
节省维护者的时间，使他们无需定期重复讲解历史背景。
确保即使项目成员发生变化，关键决策的制定方式及原因也始终清晰可查。

{% hint style="success" %} 如果项目的大部分开发讨论都在问题跟踪器中进行，可以考虑采取一些小措施，以更易于相关方和广大受众发现和获取的方式，在其他渠道突出展示这些讨论。 {% endhint %}

例如，你可以在博客、论坛帖子或项目通讯中总结该问题的讨论，这样既能保存项目的文化传承，又能向更广泛的社区通报变更。如果项目没有维护博客或其他适合此类沟通的发布机制，可以考虑在项目文档中添加关键问题列表，以便新人能快速了解这些重要主题，同时也便于长期项目参与者随时查阅。

全球高效沟通策略#

英语作为互联网的通用语言#

尽管我们生活在一个使用超过 6500 种语言的世界里，但由于历史原因，互联网交流——以及主要开源项目中使用的主要语言仍是英语。对于非英语母语用户和贡献者而言，这一事实会形成显著的参与障碍。项目方可以采取若干措施来帮助非英语母语者更有效地参与项目。

显著标注多语言社区资源#

如果你的项目被广泛采用并发展到拥有多种语言交流渠道的程度，请确保在项目网站上显著列出这些资源。在项目网站上注明：项目欢迎社区成员提交非英语撰写的资源。当项目收到此类提交时，请及时将其纳入项目文档中。

正如你向社区推荐任何资源时一样，请尽力确保该资源具有实用性。若项目当前可用人力无法验证资源的价值，请说明项目维护者尚未能亲自评估该资源的情况，同时表明欢迎社区对其纳入项目文档提出反馈意见。

无论英语水平如何都应友善相待#

正如本章多次强调的那样，与所有项目参与者保持友善、得体的沟通应成为互动的默认行为准则。当与那些用英语表达存在困难的人交流时，同样需要遵循这一原则。如果难以理解对方的表述或需求，应通过提问澄清来表明你乐意提供帮助。切勿仅因对方书面英语水平有限就忽视其存在，或宣称其在项目中不受欢迎。

{% hint style="success" %} 非英语母语者在与项目沟通时，常会因英语水平欠佳而先致歉。收到此类信息时，请感谢对方的来信，并表达对其努力与项目沟通的赞赏。如有可能，可引导他们获取更熟悉的语言资源，例如项目的西班牙语论坛或中文邮件列表。 {% endhint %}

在书面文档中避免使用习语#

每种语言都包含一些字面意思与实际含义不符的短语，比如用"over the moon"表示极度开心，或用"raining cats and dogs"形容倾盆大雨。对特定文化背景的人而言，这些短语的含义显而易见。但缺乏相关语境的人可能会感到困惑。为确保文档对所有读者都清晰易懂，请使用平实的语言替代习语表达。

展开缩略词并提供术语表#

虽然缩略词能让熟悉某领域的人省时省力，免去输入或说出完整短语的麻烦，但它们却会让不熟悉该领域的人感到困惑。此外，缩略词往往存在多义性，即同一个缩略词在不同领域可能对应不同的全称。例如，刚接触某个项目的新人可能不明白"LGTM"表示"looks good to me"（我看没问题），因此也不知道他们的工作成果已获准合并到项目源码库中。如果项目中经常使用特定缩略词进行沟通，建议花时间编写这些术语的速查表。维护这份术语表也是志愿者快速参与贡献的便捷方式。

积极寻求本地化志愿者的参与#

正如本章前面提到的，项目维护者应当始终明确他们希望从社区获得何种帮助。文档资源的本地化就是一个关键的需求领域。无论社区成员的软件开发技能水平如何，他们都可以通过翻译文档来积极推动项目发展并提升质量，从而使项目能够触达更多人群和潜在贡献者。维护者应当明确表达招募专注于本地化工作的贡献者的意愿。

记录项目的沟通规范#

当人们接触一个新项目时，他们希望了解如何才能最好地参与该项目并与社区互动。请确保你的文档清晰地列出项目的各种沟通渠道。

仅仅_列出_沟通渠道是不够的。你的文档必须明确说明_每个渠道的用途_、何时使用特定沟通机制，以及人们可以期待如何_通过该渠道接收来自项目及其社区成员的沟通信息_。例如，一个由少数维护者作为业余爱好开发的项目，可能希望在项目网站上注明开发者是利用业余时间进行工作的，因此不应期待对邮件列表咨询的即时回复。若某人的业余项目被企业使用，则可能需要明确说明帮助仅基于最大努力原则提供（这样做可以为那些不太熟悉开源项目社区运作方式的人设定合理的期望）。

保持文明对话#

正如本章通篇所讨论的，保持友善与得体的沟通对项目的持续健康发展至关重要。虽然人们可能自然而然地认为每个人都理解"友善与得体的沟通"是什么样子，但我们不能假定所有参与者对此有一致的理解，尤其是在面对全球受众时。项目维护者和社区成员以身作则固然重要，但明确阐述何为文明讨论、哪些内容与项目无关、以及项目对沟通者（尤其是涉及可能引发争议的事项时）的期望，能为项目设定恰当的基调。

摘录自Dreamwidth项目多样性声明:

我们欢迎任何性别认同或表达、种族、民族、体型、国籍、性取向、能力水平、神经类型、宗教信仰、长者身份、家庭结构、文化背景、亚文化群体、政治观点、身份认同与自我定义的人。我们欢迎社会活动家、艺术家、博主、手工艺人、文艺爱好者、音乐家、摄影师、阅读者、写作者、平凡人与非凡者，以及介于其间的所有人。我们欢迎想改变世界的人，想与朋友保持联系的人，想创作伟大艺术作品的人，以及仅仅需要工作后放松的人。我们欢迎爱好者、极客、书呆子和卷流量的IT民工挂逼。（我们也欢迎那些不确定这些黑话含义的互联网新手。）无论你上中学时互联网是否已家喻户晓，抑或万维网诞生时你早已退休——我们都欢迎你的加入。

....

通过实践积累的经验让我们深知，任何尝试都难以在初次就臻于完美。但我们仍怀揣着希望、热忱与理想主义精神，渴望不断汲取新知。虽然无法令所有人满意，但我们必定竭力避免冒犯任何群体。我们郑重承诺：若存在疏漏，当你指出时，我们将以谦逊姿态认真倾听，并全力以赴纠正过失。

这段摘录自 Dreamwidth 项目的《多样性声明》，堪称记录项目沟通规范的绝佳范例。它明确表示无论个人背景、技术水平或使用项目的侧重点如何，所有人都能在此项目中受到欢迎。声明清晰地指出犯错在所难免，并期望人们将这些不完美视为学习机会，而非贬低他人的借口。该声明告知用户及潜在贡献者：他们或许无法总是从项目维护者那里获得想要的东西，但错误会被修正，合理请求即使未被采纳也会得到倾听。尤为可贵的是，它列出的是一系列预期的_亲社会行为_，而非简单的_禁止事项_清单。声明将项目维护者和社区成员示范的行为，从具体行动转化为文字表述，帮助所有人理解哪些行为构成了优秀的项目公民素养。

行为准则#

一些项目采用行为准则来记录他们对文明讨论的期望。寻求外部贡献的开源项目都应制定行为准则。对于举办线上或线下活动的项目而言，为活动制定专门的行为准则也是最佳实践。不妨将行为准则视为项目社会契约的一部分——它既包含社区自治的规则，也明确了每位成员如何在可能采取不同行动以获得更好结果时彼此问责。这些规则必须被明确理解和阐述，否则人们既不知道对他们的期望，也无法判断这个项目是否值得投入时间和专业知识。

请参阅本指南书中关于治理的章节，以获取更多关于行为准则的信息。

与开源项目成功沟通#

迄今为止，我们主要关注了软件项目维护者如何确保项目沟通获得最佳效果。然而，贡献者同样可以采取多项措施，确保与他们钟爱的开源社区进行有效沟通。以下列举几项建议：

在参与讨论前，先阅读项目官网和文档。花时间了解项目详情并理解其细微差别。这表明你尊重项目贡献者的时间和专注力。
做好功课，并告诉大家你已经做了功课。如果使用开源软件时遇到问题，请先尽力自行解决。无法解决问题并不丢人，这反而有助于完善你的错误报告。在提交错误报告或通过项目沟通渠道寻求帮助时，务必注明你已采取的解决步骤。这样做能节省他人的时间和精力，因为维护者不会要求你重复已经尝试过的方案。列出你已尝试的自助方法，是对项目维护者时间与精力的尊重。
遵循基本的网络礼仪。互联网交流中最基本的建议同样适用于开源项目和社区。例如，避免全用大写字母输入，因为这种形式会被视为咆哮（而没有人会通过咆哮来求助）。选择一个合理且易于接近的用户名或昵称，否则你可能无法被他人认真对待。在尝试通过其他沟通渠道获取回应前，请给予合理的时间（比如 24 到 48 小时）等待对你的询问的回复。如果你不熟悉网络交流的基本规则，弗吉尼亚·希亚（Virgina Shea）常被引用的《网络礼仪核心规则》可能是一个有用的资源。
在合适的地方发布问题和交流信息。人们在不预期的地方遇到信息会感到困扰。例如，使用项目的问题跟踪器来通知大家下周要举办黑客松就不合适。如果项目已经花时间告知贡献者提问的方式和渠道——你应该通过遵循本清单第一条的指引了解这点——请务必使用恰当的论坛进行交流。这表明你投入了时间和精力，按照项目维护者和其他志愿者要求的方式与他们互动，体现出你尊重他们的付出，进而让他们更易于帮助你取得成功。
尽量让帖子标题富有意义。在撰写邮件或论坛帖子的标题时，要明确表达需求。例如，标题为"我想我发现了一个漏洞"的帖子，其处理速度很可能比"升级至 2.2 版本后外接显示器无法识别"慢得多。第二个标题向读者表明，他们很可能会找到更多关于如何诊断问题的细节，同时表明发帖者理解读者时间和注意力的有限性。第一个标题则完全无法区分发帖者的问题，使得你的沟通难以给读者留下印象。帖子标题越有用，你就越有可能获得及时回复。
在任何交流中都要保持友善与礼貌。再次强调，无论开源软件还是其他项目，有效沟通的关键在于体贴和得体的行为。不要怒气冲冲地出现在开源项目中，强硬地要求解决你的问题；没有得到即时回复时，别发送不礼貌的催促信息；也不要对交流对象表现出任何不友善的态度。务必花时间感谢他们提供的帮助，以及为所有人贡献的这个项目。请记住，你是在和他人沟通，其中有些人正利用业余时间为你编写免费软件。以你希望获得的尊重与礼遇对待他们。

开源项目和学术界中沟通的发展#

尽管开源软件如今似乎无处不在，但我们应该记住，自由与开源软件运动仍处于早期阶段。Linux 操作系统的开发始于 1991 年。管理着全球众多顶尖开源项目的 Apache 软件基金会则成立于 1999 年。虽然二三十年在互联网时代看似久远，但值得提及的是，埃达·洛夫莱斯早在 19 世纪 40 年代就创造了世界上首个算法。在更漫长的技术发展历程中，开源仍是短暂却重要的一瞬。

由于开源对软件行业的颠覆性影响，学术研究者发现开源软件项目及其开发方法尤其值得研究。

然而，随着项目沟通工具和平台的发展演变，研究人员为研究目的获取项目数据的能力有时会有所削弱。例如，解析项目中实时聊天的 IRC 日志通常能获得关于特定项目的丰富信息，但随着一些项目迁移至其他聊天系统，这类日志已不再普遍可用（且根据项目选择的沟通工具不同，其聊天记录的保存期限也无法得到保证）。

当一个项目启动或由一小群人协作时，沟通方式和平台的选择往往自发形成，很少考虑这些选择未来的影响。但项目维护者应当深思熟虑，如何确保项目沟通内容——包含潜在丰富的数据源和历史记录（如项目传说和决策历史）——能被项目参与者和感兴趣的观察者有效获取。要了解研究者如何衡量社区活跃度并分析项目各环节产出，建议参考开源软件社区健康分析（CHAOSS）项目的研究成果。

结论#

在开源项目中实现高效沟通的最佳方式是以善意和礼貌待人，初次接触素未谋面者时秉持善意揣测。尽管本章包含众多有效沟通的最佳实践指南，但以优雅姿态待人始终是达成良好沟通的首要前提。请牢记：屏幕另一端阅读你文字的是有血有肉的人，请以你期望获得的同等尊重相待。