RFD 1请求讨论

我们在成立公司时做的第一件事之一就是创建了一个回收单，这个回收单包含了我们的讨论请求。布莱恩在网上调侃了这件事。

就这篇文章而言，我们在@OxecComputer实际构建的第一件事是用于设计文档和讨论的基础设施--就像许多问题一样，这比看起来更麻烦！Https://t.co/w8ecNNUN0I。

-布莱恩·坎特里尔(@bcantrill)2020年7月22日。

描述RFD的最佳方式是使用RFD 1请求进行讨论。下面是RFD。

写下想法很重要：它允许严格地制定(即使是在刚刚起步的时候)、坦率地讨论和透明地分享。我们在请求讨论(RFD)中捕获了想法的书面表达，这是一个遵循IETF征求意见请求的原始精神的文档，如RFC 3所表达的：

笔记的内容可以是与软件或网络其他方面有关的任何想法、建议等。笔记被鼓励是及时的，而不是润色的。没有例子或其他细节的哲学立场，没有引言或背景说明的具体建议或实施技术，以及没有任何尝试回答的诱导性问题都是可以接受的。笔记的最小长度是一句话。

清楚说明这些标准(或没有标准)有两个原因：第一，有一种倾向，认为书面声明本身具有权威性，我们希望促进不那么权威的想法的交流和讨论；第二，对于不完善的东西，人们自然会犹豫不决，我们希望减轻这种抑制。

与RFC类似，我们的RFD的理念是允许及时讨论新的想法，同时仍然成为更多已建立想法的永久存储库。根据RFD的状态，RFD可以在分支机构中快速迭代，作为待合并的Pull请求的一部分进行积极讨论，或者在发布后进行评论。的RFD过程的工作流基于Golang Proposal Process、Joyent RFD Process、Rust RFC Process和Kubernetes Proposal Process的工作流。的RFD过程的工作流基于Golang Proposal Process、Joyent RFD Process、Rust RFC Process和Kubernetes Proposal Process的工作流。

以下是适用于RFD的示例，这些示例应该是宽泛的：

RFD不仅适用于技术想法，也适用于整个公司的想法和流程。如果你有一个想法来改善公司做某事的方式，你就有能力通过增加讨论来发出自己的声音。

在每个RFD文档的开头，我们希望包含少量元数据。元数据格式基于python-markdown2元数据格式。它如下所示：

作者：RFD的作者(因此也是所有者)。应该列出他们的姓名和电子邮件地址。

讨论：对于处于或超出讨论状态的RFD，这应该是到PR的链接，以集成RFD；有关详细信息，请参见下面的内容。

处于预讨论状态的文档表示该工作尚未准备好进行讨论，但RFD实际上是一个占位符。预讨论状态表示为了将RFD推进到讨论状态，正在其分支中的RFD上立即进行工作迭代。

处于构思状态的文件只包含对RFD将涵盖的主题的描述，提供了对最终RFD范围的指示。与预讨论状态不同，不存在正在进行积极修改的期望。这样的文档是相关想法的草稿纸。团队中的任何成员都鼓励在有或没有原作者参与的情况下开始积极开发这样的RFD(将其移动到预先讨论状态)。至关重要的是，处于构思状态的RFD清晰且定义狭隘。

正在积极讨论的文档应该处于讨论状态。此时，正在对拉入请求中的RFD进行讨论。

一旦(或如果)讨论已收敛，且拉入请求已准备好合并，则应在合并前将其更新为已发布状态。请注意，仅因为某些内容处于已发布状态并不意味着它无法更新和更正。有关详细信息，请参阅对RFD部分进行更改。

讨论前状态本质上应被视为工程师笔记本的协作扩展，讨论状态应在积极讨论某个想法时使用。这些状态不应用于组织上或其他方面已承诺的想法；当某个想法代表共识或方向时，它应处于已发布状态。

一旦一个想法完全实现，它就应该处于已提交状态。对处于已提交状态的想法的评论通常应该作为问题提出--但如果该评论表示要求从扩展到已承诺的功能发生重大差异，则可能需要一个新的RFD；就像在所有事情中一样，请使用您最好的判断力。

最后，如果一个想法被发现是不可行的(即故意从未实现)，或者如果一个RFD应该以其他方式指示它应该被忽略，那么它可以进入放弃状态。

我们将更详细地讨论这一点。让我们一起来看看RFD的生活吧。

如果您希望手动创建新的RFD，或者更详细地了解该过程，请继续阅读。

注意：在整个过程中，任何时候都不能直接推送到最大的分支。一旦您的分支机构包含RFD的拉取请求(PR)合并到MASTER中，则RFD将出现在主分支机构中。

您将首先需要为您的RFC预留您想要使用的号码。从当前的git Branch-r输出来看，该号码应该是下一个可用的RFD号码。

现在，您将需要创建一个新的GIT分支，以您要保留的RFD编号命名。如果小于4位，则此数字应具有前导零。在创建分支之前，请验证它是否尚不存在：

如果您在那里看到分支(但不是RFD inmaster中的相应子目录)，则可能是当前正在创建RFD；在继续操作之前，请停止并与同事核实！一旦您确认分支不存在，请在本地创建并切换到该分支：

$mkdir-p RFD/0042$cp PRODUTIES/Prototype.md RFD/0042/readme.md#或者如果您更喜欢asciidoc$cp Prototype/Prototype.adoc RFD/0042/readme.adoc。

在新文档中填写RFD编号和标题占位符，并添加您的姓名作为作者。此时RFD的状态应为预讨论。

如果您的首选是使用asciidoc，这也是可以接受的，但是此流程中的示例将假定为降价。

$git add RFD/0042/readme.md$git Commit-m'；0042：添加RFD<；标题>；'；$git推送原点0042的占位符。

推送分支后，主分支上的自述文件中的表将使用新的RFD自动更新。如果将来更改RFD的名称，该表也会更新。每当有关RFID状态的信息更改时，这也会更新该表。关于RFD的信息的单一真值来源来自分支机构中的RFD，直到它被合并。

现在，您可以收集您的想法，使您的RFD达到您希望获得反馈并与他人讨论的状态。建议远程推送您的分支，以确保您所做的更改与遥控器保持同步，以防您的本地损坏。

在公开征求反馈意见之前，你是否愿意把所有承诺压成一份，还是为了历史而保留共有权，这由你自己说了算。这取决于你是否愿意在公开征求反馈意见之前把所有承诺都压成一个字，或者你是否愿意为了历史的缘故而保留共有权。

当您准备好获取有关RFD的反馈时，请确保您的所有本地更改都已推送到远程分支。此时，您可能需要将RFD的状态从预先讨论更改为完全成形的RFD的讨论，或者更改为仅指定主题的RFD的构思。在您的分支中执行此操作。

与您的RFD内容一起，在您的分支机构中将RFD的状态更新为讨论，然后：

在giHub上打开拉取请求，将您的分支(在本例中为0042)合并到主分支。

如果您提出您的RFD讨论，但未能打开一个拉取请求，一个友好的机器人将为您做这件事。如果您打开拉取请求，但未能将RFD的状态更新为讨论，则机器人将通过将其移动到讨论来自动更正该状态。机器人还将清理拉取请求的标题为RFD{num}{title}。机器人会自动将指向PULLREQUEST的链接添加到DRANSPOSION：METADATA。

拉取请求打开后，订阅回购的任何人都会收到通知，告知您已打开一个请求，并且可以阅读您的RFD并提供任何反馈。

您选择接受讨论中的意见取决于您作为RFD的所有者，但是您应该对您参与讨论的方式保持同理心。

对于那些对拉请求提供反馈的人，请确保所有反馈都是建设性的。设身处地为他人着想，如果你要发表的评论不是你希望别人评论你的RFD，那么就不要发表评论。

在人们有时间留下评论之后，RFD可以合并为主文件，并从讨论状态更改为已发布状态。时间由您自行决定：您决定何时打开拉取请求，并决定何时合并它。作为指导原则，在合并之前有3-5个工作日对您的RFD发表评论似乎是合理的-但情况(例如，时区、特定专家的可用性、RFD的长度)可能会规定不同的时间线，您应该使用您的最佳判断。一般说来，您应该使用您的最佳判断。一般来说，在合并之前有3-5个工作日对您的RFD发表评论似乎是合理的-但情况(例如，时区、特定专家的可用性、RFD的长度)可能会决定不同的时间线，您应该使用您的最佳判断。一般来说，您应该使用您的最佳判断。如果没有人在读你的RFD，那就是时候明确要求别人给它做广告了！

讨论可以在发布的RFD上继续！讨论：元数据中的链接应该保留，允许继续讨论原来的拉请求。如果一个问题值得更多关注或本身有更大的讨论，可以打开一个问题，由概要指导讨论。

中关于RFD的任何讨论仍可以在原始拉式请求上进行，以将蔓延控制在最小限度。或者，如果您觉得合并后的评论需要更大的讨论，可以就其打开一个问题--但一定要在问题概要中反映讨论的焦点(例如，RISC-V&34；RFD 42：添加对RISC-V&34；的考虑)，并确保链接回问题描述中的原始PR，以便一个问题可以完成另一个问题。

在您的RFD合并后，始终有机会进行更改。更改RFD的最简单方法是使用您想要进行的更改进行Pull请求。如果您不是RFD的原始作者，请以RFD编号(例如0001)命名您的分支，并确保@您的Pull请求中的原始作者以确保他们看到并批准这些更改。

对RFD的更改将经过与上述相同的讨论和合并过程。

一旦实现了RFD--也就是说，一旦它不是某个未来状态的想法，而是一个系统如何工作的解释--它的状态就应该被提交。这种状态本质上与已发布的状态没有什么不同，但它代表了已经得到更充分发展的想法。虽然关于已提交的RFD的讨论是允许的(并且允许进行更改)，但预计它们不会经常出现。

关于RFD流程最好的部分是它本身在这个RFD中表达；如果您想要更改流程本身，您可以将RFD流程应用于它自己的RFD：加入讨论链接，或者按照当前状态的指示打开一个问题！

因为RFD是我们所做的一切的核心，所以我们自动更新所有RFD的CSV文件，以及它们的状态、链接和repo中的其他信息，以便于解析。然后，我们在RUST中有了一些功能，使我们可以轻松地获取这些信息，并使用RFD数据实现自动化或编程加工。

正如您可以想象的那样，跟踪RFD及其链接的规模太大了。为了帮助您，我们提供了简短的URL。您可以使用{num}.rfd.oxide.computer链接到GitHub上的任何RFD。例如，12.rfd.oxide.computer。路径也可以：rfd.oxide.computer/12(如果愿意的话)。

在聊天中，您可以使用！rfd{任何文本}|{rfd number}返回有关该rfd的信息。例如，！RFD%1返回指向RFD%1的链接、其讨论(如果它正在讨论中)以及有关其状态的信息。记住RFD的数字通常很困难，所以你传递给机器人的任何字符串都将在RFD标题之间进行模糊匹配。！RFD用户API将返回标题与文本匹配的RFD。在本例中，它是RFD 4。

作为与潜在客户、合作伙伴和公司朋友等其他各方共享某些RFD的方式，我们创建了一个网站，将RFD降价或asciidoc以良好的格式呈现为HTML。这是一种很好的GetFeedback方式，无需将每个人都添加到repo中(也可以很好地格式化内容)。

这就是总结！如果您曾经考虑在内部执行相同类型的流程，希望这会对您有所帮助！