此页面由 Cloud Translation API 翻译。

Fuchsia API 委员会章程

概览

本文档介绍了 Fuchsia API 委员会，该委员会他们负责 Fuchsia API 的质量和长期健康表面。委员会将与创造者以及修改 Fuchsia 的 API，以引导这些 API 的发展。委员会将明确传达自己的决定，包括基本理由，以及将通过提高 Fuchsia 的 API 可读性来记录最佳实践评分准则。

定义

Fuchsia 系统接口是 Fuchsia 的二进制接口，提供给系统上运行的软件。例如，进入 vDSO 以及系统使用的所有 FIDL 协议的入口点是 Fuchsia 系统接口的一部分。

客户端库是指为 Fuchsia 编写软件的人员可能会用到的库而不是直接与 Fuchsia System 对接，界面。例如，FDIO 是一个客户端库，提供类似于 POSIX 的基于 Fuchsia 系统中的底层 fuchsia.io 协议进行抽象化处理界面。

Fuchsia IDK 是 Fuchsia 的库、元数据和工具的集合项目向编写 Fuchsia 软件的人员提供。除此之外， Fuchsia IDK 包含 Fuchsia 系统接口的定义以及客户端库的数量

Fuchsia API Surface 是我们在 IDK 中包含的一组工件。这包括但不限于 Fuchsia 系统接口、 Fuchsia IDK 中包含的客户端库、IDK 元数据以及核心 Fuchsia 开发者工具。

紫红色贡献者是指参与创建紫红色的用户包括 Google 员工和非 Google 员工。

Fuchsia API 设计人员是指创建或修改 Fuchsia API Surface 的人员，其中包括 Google 员工和非 Google 员工。

最终开发者是指编写使用 Fuchsia API 的软件的人员表面。

用户是指使用运行 Fuchsia 操作系统的设备的用户。

目标

Fuchsia API 委员会的最终目标是培养健康的围绕 Fuchsia 操作系统的软件生态系统进行构建。培养健康需要平衡许多问题，包括促进生态系统的发展和引导整个生态系统朝着特定成果迈进。

值

这个生态系统中的许多参与者扮演着许多不同的角色。理想情况下能够设计出满足生态系统中所有人需求的 API 但 API 设计人员经常需要根据工作需要权衡利弊。委员会应该帮助 API 设计者做出这些决策同时尊重下列选区优先级：

用户
最终开发者
撰稿人
API 设计人员
委员会成员

例如，我们应该设计能够保护用户隐私的 API，即使是无法满足最终开发者所有期望的代价。同样，我们应设计出对最终开发者更佳的 API，即使这些设计也是如此给实现 API 的人员带来了更高的负担。

这些价值观有助于引导生态系统满足用户需求，从长远来看，可促进生态系统的健康发展，更有可能加入并持续留在这个能够满足客户需求的生态系统中。

策略

为实现这些目标，委员会重点关注以下指标：

功能。委员会负责 Fuchsia API Surface。具体而言，功能是指满足生态系统参与者的需求例如，委员会是对我们的 API 在保护用户隐私方面的作用以及我们的 API 可帮助最终开发者完成给定任务，以及我们的 API Fuchsia 贡献者会不断改进其实现方式。
易用性。委员会负责 Fuchsia API 的可用性表面。例如，委员会应力争在我们的 API 中表达了类似的概念，这使得我们的 API 更易于供最终开发者学习同样，委员会应确保我们的 API 文档资料齐全，并且从 Google Cloud 运维套件来看，接口的语义其声明。
对系统的影响。委员会需承担该体制的责任，因使用 Fuchsia API Surface 产生的全部费用，包括预期用途和意外使用。例如，使用轮询的 API 会强制执行给系统带来巨大的负担，因为它们要求其客户端以持续监控天气状况的变化。评估系统影响需要大量的判断力和经验，尤其是在预测 API 的意外使用情况。
沟通清晰度。委员会明确负责向 Fuchsia 传达决策及其背后的依据贡献者。这类沟通应能公开透明地介绍决策过程，并且应该有助于 API 设计人员了解如何打造高质量的 API。例如，委员会应该记录最佳为 Fuchsia 的 API 可读性评分准则贡献力量。
客户满意度。委员会负责协作积极地与 API 设计人员进行交流。委员会应营造一种环境委员会成员和 API 设计人员通力合作，共同改进 Fuchsia API SurfaceAPI 设计人员应将该委员会视为提供积极价值，帮助他们开发更好的 API，而不是依靠官僚主义负担例如，议会成员应及时回应，并尊重 API 审核请求。

成员资格状态

委员会由已证明以下行为的 Fuchsia 贡献者组成：

正确判断 API 的质量和长期运行状况， Fuchsia 或过去使用其他平台工作的经验。
API 设计人员认为具备很强的沟通和协作能力（即其协作者）。

成员由项目的每个职能领域指定。

该委员会由紫红色工程委员会监管。

议会设有主席，由 Fuchsia 领导层指定推动了 Fuchsia 工程委员会的运营。这把椅子有以下职责：

安排会议。
设定每场会议的议程。
评估议会是否已达成粗略共识。

功能领域

领域	主要	次要
蓝牙	jamuraa@google.com	silberst@google.com
组件框架	geb@google.com	dgilhooley@google.com
开发者	wilkinsonclay@google.com	chaselatta@google.com
诊断	crjohns@google.com	miguelfrde@google.com
推动因素	cja@google.com	jocelyndang@google.com
驱动程序 SDK	jocelyndang@google.com	cja@google.com
体验	chaselatta@google.com	ianloic@google.com
FIDL	ianloic@google.com	无
Firmware	dpursell@google.com	无
外部 ABI 兼容性	lindkvist@google.com	qsr@google.com
图形	jbauman@google.com	emircan@google.com
HCI	neelsa@google.com	emircan@google.com
身份信息	无	无
Kernel	cpu@google.com	abarth@google.com
媒体	dalesat@google.com	ypomortsev@google.com
指标	frousseau@google.com	无
Netstack	brunodalbo@google.com	无
电源	mbrunson@google.com	prashanthsw@google.com
产品组装	aaronwood@google.com	awolter@google.com
安全性	无	无
会话	quiche@google.com	neelsa@google.com
软件交付	galbanum@google.com	etryzelaar@google.com
存储	csuter@google.com	无
测试	anmittal@google.com	crjohns@google.com
工具链	mcgrathr@google.com	无
查看系统	emircan@google.com	neelsa@google.com
虚拟化	无	无
网站	wez@google.com	ianloic@google.com
WLAN	silberst@google.com	jamuraa@google.com

随着项目的推进，功能区域列表（以及结构理事会成员）。功能区域列表会保留由 Fuchsia 领导层负责。

在考虑添加某个区域时，委员会会考虑以下因素：

覆盖率。此区域是否已被其他某个区域覆盖，或者是否存在间隙？
范围。该区域是否足够大，可以安排专人指定？
持续的需求。以前是否需要这样做？

决策过程

如果议会被要求做出决定，决定流程如下：。相关地区的议会成员是主要决定制定者，但整个议会是最终决策者。整个委员会会根据主席的评估，以大致一致的方式做出决策。

主要决策者可以推迟某个决定，在这种情况下，议会将作出决定。如果委员会未能达成粗略的共识，主席将作出最终决定。
委员会成员可以要求委员会推翻初选决定制作工具。如果委员会未能达成粗略的共识，。

Operations

该委员会有两大职能：API 审查和 API 校准。

API 审核

对 Fuchsia API Surface 的每项更改都需要获得委员会成员的批准。特定功能领域的变更通常应获得负责该地区的议会成员，但任何议员都可以批准更改。

在合并之前，修改 Fuchsia API Surface 的每项更改都必须收到以下 API 的成员提供的 API-Review+1： api-council@fuchsia.dev。 Code-Review+2。同一个人可以同时提供 API-Review+1 和 Code-Review+2 特定更改请参阅评价标签，查看相关文档这个 Gerrit 功能。API 委员会成员不能提供自己的 CL API-Review+1，除非这些更改是轻微且无争议的（例如，文档更改）。尽管如此，第二位议员的独立评论。

对于细微的 API 更改，尤其是对现有 API 的增量优化，通常，API 审核人员只需进行代码审核 API-Review+1。不过，对于较大的更改，尤其是那些扩展 API 的更改 API 设计人员应撰写 RFC（请参阅 Fuchsia RFC 模板），其中介绍了 API 的设计，包括对 API 的使用案例和示例，以及安全和隐私注意事项。API 审核员可以随时要求 API 设计人员撰写 RFC，即使是小型如果 API 审核者不愿意批准更改，则会发生该更改完全通过代码审核。

要纳入 Fuchsia SDK 中，API 必须清除两个障碍：做好准备的客户，并且 API 必须通过 API 校准。

我们也鼓励 API 设计人员及早向委员会成员征集反馈意见。例如，API 设计人员应考虑分享开发中的 API 设计。与委员会成员共享文档，以便在设计过程的早期征集意见。委员会成员应该参与这些讨论，以期与 API 合作帮助设计出最佳的 API。API 设计人员还可以征求反馈意见。在议会的早期阶段就向议会征求。

API 审核人员应与 API 设计人员合作，将 API RFC 改进为以便 API 审核人员可以放心地批准文档。一个用作相关 API 的记录计划。不过，修改 API Surface 的各个 CL 仍需要审核 API-Review+1 然后再进行合并API 设计人员应知道遵循计划的 CL 应该可以轻松审核 API-Review+1，即使其他议员的意见或建议。

API 设计人员或审核人员可以询问 API RFC，即将召开的 API 校准会议议程上的主席（请参阅）。例如，API 审核人员可能会向如果 API 审核人员认为 API 审核不充分，且 API 特别复杂或重要，或者审核人员感到压力很大迫在眉睫。

API 校准

请求 API 校准

API 委员会会定期开会，共同进行 API 校准。Google Cloud API 校准的目的是促进整个项目内 API 审核的一致性，跨学科交流最佳做法，提高 API 审核质量委员会。这些会议通常配有主持人，让会议保持开启状态并帮助确保每位参与者都有机会提供反馈。

Fuchsia 贡献者可以观看 API 校准会议。观察这些会议是学习改进 API 的最佳实践的好方法。

查看包含 API 更改的 RFC

在某些情况下，更改 API 时可能需要通过 RFC 讨论建议的更改。API 校准的首要任务是审核已经引荐全体议会。如果有多个待处理文件主席负责选择议会通过文档。

编写该文档的 API 设计人员应展示该文档，并提供理事会，获得必要的背景信息，了解存在风险的问题。之后，由推荐人主持讨论他们希望获得反馈的 API 设计领域。委员会成员我们鼓励他们重点关注这些领域，但可以自由提供提供有关整个文档的反馈。

查看积压

Fuchsia API Surface 包含大量为该委员会成立之前委员会将处理积压的 API 最终达到 Fucsia API 中的每个 API 界面已经过审核。理想情况下，议会有机会审查在 Fuchsia 承诺实现向后兼容性之前，整个 Fuchsia API Surface 其 API 的组成部分。

理事会负责选择理事会处理积压工作的顺序，试图在审核项目不同领域的 API 与紧迫查看正在吸引大量客户的 API。

审核 API 时，负责该 API 的委员会成员包含 API（以下简称为负责任的成员）会显示该 API，向委员会提供必要的背景信息，帮助他们了解应用场景和开发 API 的初衷负责的成员可以邀请一个或多个主题来提供更多背景信息和技术细节。理想情况下，负责的成员应预先审查 API 并获得建议的修改的列表。

二次审核

委员会还将循环研究项目的职能领域，对每个区域的 API Surface 更改进行二次审核，最后一个月经周期通过此活动，委员会可就以下方面向会员提供反馈：最近的 API 审核。

主席将选择各个区域的审核顺序，在审核项目不同领域的 API 与确定查看涉及大量更改的 API。

在二次审核过程中， API 变更会呈现此变更以及所有相关的 API 设计文件，向议会提供必要的背景信息，帮助他们理解应用场景以及做出这些改变的动机。做出更改的 API 设计人员也鼓励（但不强制要求）参加。

一般来说，委员会应尊重在主要 API 发布期间做出的决定不过，我们鼓励委员会成员提供关于 API 如何可以改进，这有利于未来的审核。根据 API 的成熟度，主要审核员可能会决定将这些改进纳入 API 中。在极少数情况下，委员会可以推翻初选审核员批准。

致谢

本文档主要取自 Android 设备使用的治理结构， API 委员会、Web API 所有者、W3C 和 IETF。特别感谢 Jeff 分享 API 治理经验以及深思熟虑的反馈本文档的早期草稿中。