为 Scala 的 OSS 生态系统做出贡献

为 API 文档做出贡献

语言

此页面专门针对 API 文档贡献,即 Scala 标准库 的 API 文档,有时称为 Scaladoc 贡献。

有关 docs.scala-lang.org 上教程和指南样式文档的贡献,请参阅 添加新指南/教程

请注意,这些说明仅涵盖对 Scala 核心库的文档贡献。对于其他 Scala 项目,请查看这些项目以了解贡献步骤和指南。谢谢。

概述

由于 API 文档位于 Scala 源代码文件中,因此为 API 文档做出贡献的过程类似于为 Scala 代码库做出错误修复的贡献,但不需要首先在 GitHub 上提交问题。在分叉/分支时,使用 scaladoc/xxxx 分支名称会有所帮助,其中 xxxx 是一个描述性但较短的分支名称(例如 scaladoc/future-object)。但是,如果确实存在问题,请改用 issue/NNNN,其中 NNNN 是工单号。

如果您想协助我们,您可以 报告缺失/不正确的 API 文档,或 贡献新的 API 文档

贡献 API 文档错误报告

做出贡献的一种好方法是帮助我们识别缺失的文档。为此,浏览当前 API 文档并识别缺失、不正确或不足的文档。一个好的起点是重要包的包对象(这些对象通常会被文档忽略,并且是 API 概述的理想位置)。

如果您发现问题,请在 Scala 错误跟踪器(或 Scala 3 错误跟踪器,用于 Scala 3 库添加)中记录该问题,前提是确保该问题尚未记录为错误。为了帮助消除歧义,请对问题标题使用以下格式

  • 使用描述所需工作的操作,例如 添加记录更正删除
  • 使用完整包、类/特性/对象/枚举名称(或在这种情况下为状态包对象)。
  • 对要执行的操作的极简描述。
  • 更多详细信息可以(并且应该)放入问题描述中,包括对问题的一个简短说明(如果提供了其他详细信息)。

下面是示例 API 文档问题标题和描述的示例

记录 scala.concurrent.Future 对象,包括代码示例

(注意标题中明确指出的伴随对象)

以及描述

Future 伴随对象上的方法对于有效使用 Future 而不会阻塞至关重要。提供如何使用 sequencetransformfoldfirstCompletedOf 等方法的代码示例。

除了遵循这些约定之外,请向问题添加 documentationcommunity 标签,并将它们放入 Documentation and API 组件中,以便它们显示在正确的 issue 过滤器中。

贡献新的 API 文档

必读

在为新的 API 文档做出贡献之前,请熟悉以下内容,以节省时间、精力、错误和重复。

  • 分叉仓库 - 按照设置步骤完成分支部分。如果提供与现有 GitHub 问题相关的新的文档,请使用 issue/NNNNticket/NNNN 作为指南中所述。如果提供没有关联的 GitHub 问题的 API 文档,请改用 scaladoc/xxxx
  • 面向库作者的 Scaladoc介绍了 scaladoc 标记、markdown 和其他功能的使用。
  • Scaladoc 的界面介绍了 Scaladoc 界面所有功能,例如在伴随对象之间切换、浏览包对象文档、搜索、标记搜索等。
  • 提交之前,务必阅读关于 git 提交消息的说明Scala 项目和开发者指南。后一文档中的一些内容显然不适用(例如关于提供测试的部分,但请参阅以下关于文档的一些特殊要求)。不过,仍然要阅读整篇文档,并密切注意标题和提交消息格式,注意现在时长度限制以及必须干净地合并。请记住,合并时,请求合并的标题将成为提交消息。此外,务必为 PR 分配一个或多个审阅者,如果您无法做到这一点,您可以在请求合并的评论中提及一位用户。

Scaladoc 文档提交的额外要求

虽然 API 文档提交不需要满足错误修复请求合并的一些要求,但以下是有助于确保您的 API 文档 PR 顺利合并的分步要求

  • 提供的所有代码示例都应正确、编译并按预期运行(在 REPL 或您的 IDE 中确保这一点)。
  • 在可能的情况下,必须检查所有书面语言代码示例的拼写。大多数编辑器都提供一些拼写检查功能。Scala 代码本身允许不通过拼写检查,但应检查所有书面语言。如果您还可以使用语法检查器,它将有所帮助。在接受之前,我们会要求更正拼写和语法。
  • 必须运行 sbt doc,修复任何问题,并检查更改的格式和布局。同样,如果格式或布局不充分,将需要更正。运行 sbt doc 后,可以在 build/scaladoc/ 文件夹(可能在 library 子目录中,但根据您正在处理的 Scala 源代码的部分,也可能在其他子目录中)下找到生成的文档。
  • 所有这些步骤都是必需的,以节省审阅者和贡献者的双方时间。确保合并 PR 的流程尽可能顺畅和精简,这对每个人都有好处。

感谢您帮助我们改进 Scaladoc API 文档!

本页的贡献者