理解社区角色#

在开源社区中,个体角色的界定取决于其参与方式、协作模式以及对社区及各类社区产出的贡献。人们常误以为为开源项目贡献价值的唯一或最佳方式就是编写代码,这其实是一种普遍存在的误解。有句谚语道:"所有贡献都具有同等价值",这恰当地概括了最可取的态度。

其中一部分原因在于我们根本无法预知未来——你确实无法预判哪项贡献或哪位贡献者将对项目产生持久影响。例如,大量微小贡献的累积效应,很可能与少数几个引人注目的大型贡献产生同等影响力。某位参与者可能只是短暂参加了用户体验研讨会,却在无意间通过这次短暂互动提供了具有持久价值的见解。

所有贡献应被平等对待的核心意义在于:社区由人组成,而这些人的情感与体验本质上就是社区本身。每个人为社区带来的贡献——无论大小——都成为项目中极具个人色彩的"货币",通过这些贡献,我们能辨识谁在哪些方面值得信赖。

在一个开放包容的社区中,随着成员技能的持续成长,无论其贡献性质如何,其影响力终将超越个体局限。当人们被允许突破角色边界、不断挑战自我时,他们就能释放最大潜能。这种"被允许"体现在:消除对不同类型贡献的价值评判、等级差异乃至羞耻感。

因此,这是一种认同所有人具有平等价值的方式,他们每日的付出都应被视作当下人性最美好的体现。这种包容之道意义深远,它允许人们成为百分之百的贡献者——无论他们在特定日子里以何种方式参与或表现。

贡献方式#

思考如何为你希望加入的项目或团体作出贡献永远不会太早。这样做不仅能推动项目更好地满足你和所有用户的需求,还能让你获得认可、在安全环境中提升技能,并通过合作者拓展人脉网络。

本文档涵盖了贡献者扮演的多种角色。你或许会感兴趣:学术论文的CRediT项目对这些角色有着怎样相似或不同的定义。

文档撰写#

文档资料与培训材料对于新人招募和团队新成员快速上手至关重要。编写技术文档是最被低估的重要贡献之一。正如某位博主所言:"计算机文档长期处于类似政府拨款的尴尬境地:没人愿意出力编写,但每个人都希望需要时能随手可得。"本节将逐步指导你如何创建文档。

提议一份文档#

如果你发现某个项目或团队的文档存在缺失,可以直接联系项目负责人或在社区论坛询问是否有人正在撰写相关主题的文档。在 GitHub 和 GitLab 等支持"问题追踪"的平台上,你也可以通过创建 issue 来申请文档,但更简单的做法是先非正式地询问是否已有人在编写此类文档。

若发现已有人正在编写你认为必要的文档,可以主动申请成为审阅者。有时你甚至能以作者身份参与协作,但作者必须注意清晰明确地划分不同作者负责的主题范围。文档的模块化程度通常不如软件代码。

如果确认无人撰写该文档,且社区或项目负责人支持创建新文档,接下来要考虑的是:谁是最合适的作者?通常答案就是:你自己。虽然可能有其他更熟悉该主题的专家,但如果他们尚未创建这份文档,很可能是因为忙于其他事务、不擅长写作或其他原因。最理想的作者就是有撰写意愿的人,既然你提出了这个需求,很可能你就是最佳人选。主题专家可以为你提供思路并审核文稿。

此时应当正式发布公告,例如通过创建问题。建议设定截止日期以施加完成文档的压力。需注意文档需要经过评审,这可能会使项目延长数周。建立里程碑也很有帮助,例如:

  1. 开始撰写

  2. 分发初稿征求意见

  3. 初稿审阅周期结束

  4. 终稿传阅

  5. 终稿审阅周期结束

  6. 提交审核

  7. 审核通过并发布

项目文档需经项目负责人或顾问团队批准后方可纳入。这些领导者应以开放态度审批文档项目,因为任何与项目相关的新文档通常都能为部分成员带来价值。

成为作者#

获得领导层批准撰写文件后,请按以下步骤操作。

学习使用工具#

了解团队偏好的文档格式(如 Asciidoc、Markdown 等)。大多数项目会将文档像源代码文件一样集成管理,这样项目组就无需为文档相关任务(如提交文档错误报告)专门开发特殊工具和流程。

写作标准#

写作是一项需要不同熟练程度的技能,但遵循一些基本准则能帮助经验不足的作者撰写出实用的文档。

  • 始终考虑你的写作对象。选定主题后,明确受众是文档规划中最重要的环节。不妨自问:大多数读者是否理解我使用的专业术语?终端用户是否需要了解开发者讨论的技术细节?在讲解资源使用方法前,是否需要先说明如何找到该网页或其他资源?

  • 尽量将操作指南分解为分步骤的流程说明。这类分步指南通常最容易遵循,特别是当以有序列表形式呈现时。切勿仅凭记忆撰写:务必在编写时亲自操作一遍流程。否则,几乎肯定会遗漏某个步骤或出现描述错误。

  • 构建文档结构。保持句子简短。尝试拆分长段落。频繁设置新标题。如果你发现某个章节写了十几段甚至更多,却不知如何将其拆分为更小的部分,那你可能在组织一篇结构混乱、行文不畅的草稿。

文档撰写阶段#

通常,作者在撰写文档前应提交大纲供评审。大纲能确保涵盖所有重要主题,同时避免包含不必要的内容。评审者也可提出结构调整建议。但作者在实际撰写时,往往会找到理由新增主题或调整其位置。

相关文档引用是大多数文档的重要组成部分。正如前文所述,作者应当通过调查研究找到相关文档并予以收录。内联链接尤其有助于引导读者了解背景知识——当他们需要学习某些基础知识才能理解文档时。不过,通常在文档末尾提供参考资料章节最为实用。

审阅文档#

文档审阅采用众包模式,这意味着我们欢迎来自不同知识背景、能力水平、专业培训、种族、性别、地理位置等多元人群的审阅意见。这种方式能显著提升文档的价值与可读性。

你可以指出你认为不正确或遗漏的内容。请理解我们尽量保持文档简洁,以便忙碌的人们有时间阅读。提供优质文档和其他资源的参考信息非常有价值。

编辑、校对和拼写检查同样是宝贵的贡献方式。

审阅文档是熟悉我们语气与风格的绝佳途径,为日后撰写自己的文件做好准备。

参与指导委员会工作#

这些委员会也需要领导者。经过数月的参与后,我们希望你能考虑承担领导职责。虽然具备与团队目标相关的专业知识很有帮助,但领导者也可以通过协调成员任务、主持会议以及处理其他组织事务来发挥作用。

招募其他志愿者#

来自受尊敬的朋友或同事的个人邀请,是招募新团队成员最有效的方式。当你发现一个自己支持的项目时,不妨思考哪些人会成为团队的宝贵补充。在你充分了解项目目标及团队运作方式后,就可以主动联系潜在的新成员。

对志愿者的一般指导#

大多数志愿者都能为项目带来实用知识,并在参与过程中不断学习。你可以通过多种方式分享这些知识:在论坛和聊天中回答问题、指导他人,以及参加小组会议。

翻译软件和文档#

什么是翻译? 将软件界面和文档转换为另一种语言。最终成果是一个经过本地化的软件包,让人们能够以自己偏好的语言阅读界面和文档。

翻译人员做什么? 运用工具和流程将软件界面、文档、营销材料、版本说明等内容翻译为一种或多种语言。许多项目采用通用流程或模式,因此在一个软件项目中学习的翻译技能往往可复用于其他项目。诸如 Fedora Linux 等 Linux 发行版就拥有专门翻译操作系统各组成部分的翻译者团队,将其译为数十种语言。

为什么人们喜欢这个角色? 许多人通过将软件和文档翻译成本地语言,为开源软件的传播做出了贡献。他们以此方式将自由开源软件的益处带给本地社区。

协助管理项目系统#

什么是系统管理? 代表项目创建和维护可运行的计算机系统。根据现有系统和规划需求,该角色可能需要具备系统管理员/运维/DevOps 等多方面的经验。

系统管理员负责哪些工作? 负责项目底层基础设施的各方面工作。这些基础设施为项目参与和协作提供支持途径。

为什么人们喜欢这个角色? 学习新技能并接触新技术。通常人们即使没有专业经验,也会对此类工作抱有倾向或将其作为严肃的爱好。特别是在现代自动化技术影响下,系统管理员的角色正在持续演变。

筹款和组织赞助#

什么是筹款? 这是指寻找有意向为项目及社区捐赠资金、硬件或服务的个人与组织的行为。赞助形式多种多样。对于无法接收现金捐赠的项目,赞助通常表现为活动参与机会、差旅支持、展位人员协助等形式。

筹款人具体做什么? 与项目负责人、基金会等上级组织以及有意捐赠和赞助的个人或机构合作。这包括处理赞助细节,无论是一次性捐赠还是持续筹款活动的一部分,以敲定协议条款。可能还涉及后续对赞助资金、拨款或其他形式捐赠的管理工作。

为什么人们喜欢这个角色? 他们深知围绕开源社区建立可持续性的重要性,并希望有所作为。某些技能或个人特质可能使这项工作对他们个人而言更具吸引力或价值。

营销的工作范畴#

什么是市场营销? 在开源软件领域,市场营销是指推广社区及其软件成果的行为。其他实践(如市场调研和广告)通常不会在社区内部进行。

营销人员做什么? 他们与项目的各个部门协作,帮助团队理解用户的需求与期望,进而将这些信息简化并广泛传播。在开源领域,用户反馈通常以错误报告和求助形式直接流向开发团队。与封闭式软件开发模式不同,最熟悉内容和代码的贡献者往往对用户群体有着深刻认知。营销人员能协助收集、梳理、整合这些信息,并将其转化为功能规划和路线图中的优先级事项。

为什么人们喜欢这个角色? 那些对超越"一切皆数字化"视角的现代营销感兴趣的人,能在开源开发的核心流程中,看到与某些世界级品牌特质相呼应的真实、开放与透明——这些正是当代营销的深层魅力所在。

助力项目拓展推广#

什么是外联? 这项工作涉及与用户、参与者、潜在贡献者乃至整个外界建立联系。这些联系不仅限于市场营销,还可能涵盖招募、用户帮助、反馈收集、受众分析、技术支持等多个方面。

外联协调员做什么? 直接与项目中的创作者(代码、内容、设计、市场营销等)合作,充当项目与外部各论坛之间的双向桥梁。这些论坛可能是项目维护的网站或邮件列表,也可能是博客和技术记者,或是用户提问和解答问题的网站。从事外联工作的人员需要对项目的几乎所有方面有一定程度的了解,能够识别并建立项目各部分与外部世界的联系。

为什么人们喜欢这个角色? 这个角色需要深入了解人员和流程,并围绕它们进行沟通。它提供了一个机会,让那些可能在项目中默默无闻的人得以发声,帮助将这些声音带到台前。

专注于社区赋能、管理和架构建设#

什么是社区架构(及其他相关概念)? 鉴于开源项目的成功既取决于代码库也依赖于社区,大多数项目都会安排人员(正式或非正式地)承担起设计和维护社区本身的首要职责。

社区架构师负责什么工作? 作为该角色的核心职责,此人需要了解并监督或直接实施本指南中的诸多最佳实践。当这一角色由多人分担或仅为兼职配置时,相关成员通常会聚焦于与项目最密切相关的实践领域。通过这种方式,即便社区管理/赋能资源有限的项目,最终也能完成关键环节的工作。

为什么人们喜欢这个角色? 这个角色适合那些喜欢沟通、协作和连接他人的人。如果你能从见证他人成功(当然也包括帮助庆祝这些成功)中获得与自己成功时相同的快乐,那么这个角色会很适合你。这个角色也吸引那些对处理多种多样事务感兴趣且擅长的人(即多面手)。

其他技术角色#

能够为某一领域编写的软件种类繁多,这让我们对哪些内容适合纳入此处有了一定概念。这可能意味着需要特定的技术技能,比如地理信息系统(GIS)项目中需要地理学家的专业知识。这也可能涉及通用的技术能力,这在解决复杂问题时通常是必需的。

结论#

本章列举了开源项目中人们可以担任的一些角色示例。这份清单虽非详尽无遗,但针对所列角色,它提供了关于这些角色的职责以及人们为何承担这些角色的基本概念。