FreeBSD 状态报告流程
最后更新于
最后更新于
原文：
FreeBSD 状态报告每季度发布一次，向公众提供了项目的最新动态，它们通常会附带来自开发者峰会的特别报告。由于状态报告是我们最为显眼的沟通形式之一，因此它们非常重要。
在本文档中以及与 FreeBSD 状态报告相关的其他地方，状态报告 这个术语既指代每季度发布的文档，也指其中的单个条目。
本节提供了一些写作状态报告条目的建议，也包括如何提交条目的说明。
不要担心自己的母语不是英语。状态团队会检查你的条目，并修正拼写和语法错误。
不要假设阅读报告的人了解你的项目。
状态报告的受众广泛。它们通常是 FreeBSD 网站上的头条新闻，是人们了解 FreeBSD 相关信息时首先阅读的内容。考虑这个例子：
如果读者熟悉 UNIX 手册页，他们会知道 abc(4) 是某种设备。但读者为什么需要关心呢？它是何种设备？对比以下版本：
现在读者知道 abc 是一款网络接口驱动程序。即便他们不使用 Yoyodyne 的产品，你已经传达了 FreeBSD 在网络设备方面的支持正在不断增强。
状态报告不仅仅是告诉大家做了什么，它们还需要解释为什么要做这些事情。
继续前面的例子。现在我们支持 Yoyodyne Frobnicator 卡，为什么这件事值得一提？它们广泛使用吗？是否在某些流行设备中使用？是否在 FreeBSD 希望进入的特定领域有重要地位？它们是否是世界上最快的网卡？状态报告通常会包含类似这样的内容：
然后就停了，也许读者是 Cyberdyne 的忠实粉丝，知道 T800 带来了哪些激动人心的新特性，但这并不常见。大多数情况下，他们可能对你导入的内容不太了解（尤其是对于 Ports：记住那里面有 35,000 余项其他条目）。列出一些新特性或修复的 bug，告诉他们为什么我们获得了新版本是件好事。
不要重复相同的状态报告条目。
请记住，状态报告不仅仅是对项目状态的报告，它们还是项目状态变化的报告。如果某个项目正在进行中，简要介绍一下它，但接下来要专注于新工作。自上次报告以来有什么进展？还剩下什么工作？什么时候可能完成（或者如果“完成”并不适用，那什么时候可能准备好供更广泛的使用、测试、生产部署等）？
不要忘记提及你的赞助商。
如果你或你的项目获得了赞助，或者你已经作为承包商或员工为某公司工作，请在报告中提到。赞助商总是很高兴你感谢他们的资助，同时他们也会从中受益，展示他们在积极支持 FreeBSD 项目。最后，这有助于 FreeBSD 更好地了解其重要的用户。
如果需要帮助，请明确说明！
是否需要别人提供帮助？有没有任务是其他人可以完成的？你可以在状态报告中的待办事项部分用两种方式来描述：请求帮助，或者快速概述剩余的工作量。如果已经有足够多的人参与项目，或者项目处于一个不适合增加人手的状态，那么后一种方式更为合适。列出正在进行的大任务，可能还可以标明每个任务的负责人。
列出任务，提供足够的细节让人们知道他们是否能够做这些事情，并邀请他们联系你。
你可以通过以下方法提交你的报告：
本节介绍了状态报告的审阅和发布流程。
状态报告主页
状态报告存档 GitHub 仓库（用于 2017Q4 至 2022Q4 的报告）
状态团队主要电子邮件地址
提交报告的电子邮件地址
用于接收状态报告通知的邮件列表
Phabricator 状态团队主页
状态团队始终接受报告，但主要的收集过程发生在每个季度的最后一个月，即 3 月、6 月、9 月和 12 月。在这些月份，会明确发出状态报告的征集通知。1 月、4 月、7 月和 10 月则专注于整理上一季度提交的报告，这期间可能会等待迟交的报告。状态报告的发布会在报告准备好后尽快完成，通常是在同一个季度内。
提交报告的审阅工作通常应在 1 月、4 月、7 月和 10 月的中旬完成（第三方审阅期）。也就是说，除了错别字或轻微的文稿编辑外，状态团队应该在每月 15 日之后开始整理提交的报告。请注意，这并不是完全冻结，状态团队仍然可以接受审阅。
第一次报告征集通知
3 月 1 日
6 月 1 日
9 月 1 日
12 月 1 日
剩余 2 周提醒
3 月 15 日
6 月 15 日
9 月 15 日
12 月 15 日
最后提醒
3 月 24 日
6 月 24 日
9 月 24 日
12 月 24 日
标准截止日期
3 月 31 日
6 月 30 日
9 月 30 日
12 月 31 日
延期截止日期
4 月 8 日
7 月 8 日
10 月 8 日
1 月 8 日
第三方审阅期
4 月 15 日
7 月 15 日
10 月 15 日
1 月 15 日
状态报告的征集通知会发送给以下收件人：
所有上次提交状态报告的人（他们可能有更新或进一步的改进）；
根据季节变化：
各种会议组织者：
各种会议参与者：
9 月至 10 月的 EuroBSDcon（第三、四季度）；EuroBSDcon 作为一家组织对写 FreeBSD 状态报告不感兴趣——至少在 2019 年 10 月时并非如此：其原因是该会议并非专门针对 FreeBSD。因此，应向参与会议的 FreeBSD 社区成员征集关于该事件的报告。
警告 、 如果你负责发送状态报告的调用，并且确实使用了 cron 作业，请在 freefall 上运行它并签上你的名字，以便在出现问题时能够推断出是谁配置了该 cron 作业。同时，请将上面的示例更新为包含你的名字，作为额外的安全措施。
提交的报告会在收到后进行审查，并合并到 doc/website/content/en/status/ 的适当子目录中。在报告更新的同时，状态团队之外的人也可以审查各个条目并提出修正建议。
通常，内容审查过程的最后一步是写一个名为 intro.adoc 的文件中的介绍：只有在所有报告收集完毕后，才能写出好的介绍。如果可能，最好让不同的人写介绍，以增加多样性：不同的人会带来不同的观点，有助于保持新鲜感。
待所有报告和介绍准备好后，需要创建 _index.adoc 文件：这是报告按类别分发并排序的文件。
当状态报告的所有文件准备就绪后，就可以发布它了。
首先，编辑 doc/website/content/en/status/_index.adoc：更新下一个截止日期并添加新报告的链接。然后将更改推送到仓库，状态团队检查一切是否按预期工作。
接着，将新闻条目添加到 doc/website/data/en/news/news.toml 中。
以下是新闻条目的示例：
链接到渲染后的报告会添加在介绍和第一个条目之间。
最后，报告准备好发送，切换邮件的显示方式（报告应嵌入邮件正文中），并确保它以 UTF-8 编码。
发送两封电子邮件，主题格式为 FreeBSD 状态报告 - <第一/第二/第三/第四> 季度 <年份>：
重要
提交 ，并将 status 组添加到审阅者列表。你应该将报告放在 doc/website/content/en/status/ 的适当子目录中（如果缺少此子目录，创建它）；
通过 提交 pull request 到文档仓库。你应该将报告放在 doc/website/content/en/status 的适当子目录中（如果缺少此子目录，创建它）；
发送电子邮件至 ，并附上你的报告。
可以参考 。
所有报告的提交截止日期可以通过 请求延期，延期时间为季度结束后 8 天。由于状态报告和季度 Ports 分支之间的重叠，的条目默认为延期截止。
；
3 月份的 （第一季度）；
5 月份的 （第二季度）；
谷歌编程之夏的和他们的。
发送状态报告征集通知的最简单方法是使用 ，该脚本位于文档 git 仓库的 tools/sendcalls 目录中。该脚本会自动发送通知给所有预定的收件人。也可以通过定时任务来使用，例如：
也可以考虑像在论坛上发布状态报告的调用。
报告的 HTML 版本已经构建并上线后，使用 将网站转储为纯文本，例如：
完全支持 Unicode。-dump 仅输出 HTML 代码的文本渲染，之后可以删除其中的一些元素，而 -cols 确保所有内容都换行到 80 列。
一封发送到 ;
这封邮件必须获得批准，因此，如果你负责发送此邮件，请确保有人批准（如果处理时间过长，请邮件联系 ）。
一封发送到 ，并抄送到 、 和 developers@FreeBSD.org。