使文档成为开源项目优先事项的 5 个技巧

文档和代码一样重要,所以请确保你像对待代码一样对待文档。 这是方法。
63 位读者喜欢这篇文章。
Files in a folder

开源软件现在已成为主流;开源项目仅吸引开发人员的时代早已过去。如今,各行各业的用户都是开源软件的活跃消费者,你不能指望每个人仅通过阅读代码就知道如何使用该软件。

即使对于开发人员(包括那些在其他开源项目中有丰富经验的开发人员)而言,当人们加入社区时,良好的文档也是一个有价值的入职工具。 有兴趣为项目做贡献的人通常从编写文档开始,以熟悉项目、社区和社区工作流程。

开源文档的常见挑战

尽管所有人都同意文档很重要并且需要完成,但我们执行文档的一些方式导致项目文档不同部分质量低下且缺乏一致性。 例如,当开发人员过于关注代码时,他们直到最后一刻(例如,在发布之前)才开始编写文档。 而且通常,文档任务由志愿者完成,他们很难说“不”。 更糟糕的是,人们可能会在发布后忘记文档,因此他们永远不会更改或改进它,恶性循环重复。

5 个最佳实践

在过去的几年中,我们参与了 Linux 基金会网络GitLab 的许多开源项目的文档编写。 下面,我们将分享一些我们学到的东西,我们希望这些东西将有助于使文档成为你开源项目中的头等公民。

  1. 像重视代码贡献一样重视文档贡献:许多开源社区的重点往往放在代码上。 确保每个人都重视文档贡献的一个简单方法是在你的社区指标中给予文档和代码同等的重视。 提交、合并请求或拉取请求是针对代码还是文档应该无关紧要。 此外,当你进行社区表彰时,请包括文档贡献者的主要成就。

  2. 将文档和代码放在同一个项目仓库中:我们强烈建议项目的代码和文档都驻留在同一个存储库中。 (一个好方法是将 /doc/docs 作为存储库中的顶层目录。) 首先,这使任何人都可以轻松找到文档。 更重要的是,当所有内容都在同一个存储库中时,你的文档将与代码和其他项目资源处于同等地位。

  3. 将文档作为合并或发布里程碑的要求:如果你的项目发布周期较长(例如,三个月到六个月或更长时间),我们强烈建议为文档设置临时检查点(如 ONAP 社区的这个示例)。 这确保了文档工作不会推迟到发布前,而是每个人在整个发布周期中都致力于文档编写。 如果你的社区可行,你可以将文档作为所有会影响用户的代码贡献的必需步骤(参见 GitLab 的这个示例)。

  4. 为代码和文档制定一致的贡献流程:我们还建议为代码和文档制定一致的贡献流程并使用相同的工具链。 正如我们前面提到的,许多新的社区成员通过编写文档开始贡献,因为你通常不需要深入的技术软件知识即可入门。 对于新贡献者来说,通过熟悉贡献工作流程并与其他社区成员会面来加入社区是件好事。 如果这些新贡献者以后想参与项目的其他部分(包括代码),你希望工具链和贡献流程是熟悉的。 否则,他们将需要经历另一个入职流程,这会给贡献者造成不必要的障碍。 如果你的代码和文档有不同的贡献流程,你可能会冒着造成文档不如代码重要的印象的风险。

  5. 拥有完善的文档贡献流程:这似乎是显而易见的,但很容易被忽视。 由于文档是新贡献者的良好切入点,因此你希望尽可能降低入门门槛。 拥有关于贡献工作流程、如何入门、在哪里找到要处理的问题、如何获得帮助等的良好文档,将大大有助于新贡献者感到受欢迎并参与到你的社区中。

还有什么?

你是否有其他使文档成为开源社区中头等公民的技巧? 如果有,请在评论中分享。


本文基于 2020 年 6 月在北美开源峰会上提出确保文档成为开源项目中的头等公民

接下来阅读什么
标签
User profile image.
Ray 是 PingCAP 的社区经理,他在那里帮助发展 TiDB 社区。 在加入 PingCAP 之前,Ray 在 Cube Dev、GitLab 和 Linux 基金会管理开源社区。 他在科技行业拥有超过 15 年的经验,曾在 EDS、Intel 和 Medallia 等公司担任软件工程师、产品经理、项目经理和团队主管等职位。
User profile image.
作为爱立信软件技术 (EST) 组织的一员,Sofia 参与推动开源参与,支持建立 EST 业务,并在整个爱立信公司倡导开源。 她是 Linux 基金会网络中文档的技术负责人,也是 Nordix 基金会的社区经理。

4 条评论

我认为,如果不是必不可少的,那么开发人员和编写文档的人员之间进行良好的沟通非常重要。 首先,这是文档编写者了解新功能,或者现在以不同方式工作的旧功能的最佳方式。 此外,文档编写者可以就某些未按设计工作或可以通过稍微更改代码更有效工作的内容提供反馈。 所以这是一个双向的街道。

这是真的,但很多项目真的忽略了文档。

“我们有这个很棒的 API” - 这太棒了,但如果我们可以在不浏览代码的情况下知道如何使用它,那就更好了!

很高兴看到这篇文章,Sofia 和 Ray。 我完全同意。 我很欣赏你们指出了使贡献尽可能容易和一致的细微之处。 此外,还要像重视代码一样重视文档贡献。

我建议添加赞助商从角色的角度批评文档的底层平台和信息设计。 这对于典型的贡献者来说是不太可能的过程,但可能会非常具有启发性。

赞助商需要清楚地了解贡献者能够做什么以及还剩下哪些差距。

知识共享许可本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© 2025 open-source.net.cn. All rights reserved.