Appearance
TEP: 1 - 生命周期
- TEP: 1
- 标题: TEP 生命周期
- 状态: 活跃
- 类型: Meta
- 作者: Vladimir Lebedev
- 创建日期: 11.06.2022
- 替代: -
- 被替代: -
摘要
本文档介绍了 TEP -- TON 增强提案。TEP 是一种设计文档，描述了 TON 的某个部分，例如 ADNL（节点之间的网络协议）或 NFT（通用智能合约接口）。
动机
当前的 TIP 系统过于非正式，无法高效地管理编写、讨论和接受新标准的过程。TON 需要一个新的提案流程，鼓励作者深入探讨主题并详细记录所有要点，以便与社区进行建设性讨论。
指南
对于作者
如果你有提案的想法，先在社区中讨论，例如在 TON 开发者聊天群中 (英文/俄文)。讨论可以帮助你快速发现潜在的漏洞，并避免在编写实际提案时浪费大量时间，因为你可能会发现你的想法并不像你之前认为的那样清晰。你还可以先浏览 TEP 模板 并考虑每个部分，然后再开始编写。
当你觉得自己准备好编写时，只需 fork 这个仓库并将模板复制到 ./text/0000-my-new-standard.md，其中 "my-new-standard" 是你的 TEP 的简短标题。填写所有部分并回答模板中提出的问题。如果需要包含图片或其他附加文件，请将它们上传到 ./assets/0000-my-new-standard/ 文件夹中。
尽量尽可能详细地回答模板中的问题。当提案准备好后，打开一个 拉取请求，并准备好与社区讨论你的提案。在审核过程中，如果有必要，请对你的拉取请求进行修改。
对于审核者
在创建拉取请求后，任何具有相应经验的开发人员（无论是来自 TON 基金会还是社区）都可以请求仓库维护者将其指定为拉取请求的审核者。任何人都可以评论拉取请求，但审核者必须投票决定是否合并或拒绝拉取请求。一旦大多数人投票赞成或反对，TEP 将进入最终评论期。
FCP 持续 10 个日历日，在此期间 TEP 会被广泛宣传。这样所有利益相关者都有机会对 TEP 发表最终评论。有时 FCP 必须取消，因为提出了新的论点/想法。在这种情况下，讨论重新开始，审核者必须再次投票。
规范
本节正式描述你的功能。它包含必须遵循的要求，以便实施你的 TEP。为了保持正式性，遵循 RFC 2119 是方便的。你应该在本节开头包含以下文本：
本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按照 RFC 2119 中的描述进行解释。
TEP 角色
- 作者
- 编辑
- 审核者
TEP 创建
作者应该复制 TEP 模板 到 ./text/0000-my-new-standard.md 并填写所有部分。作者可以包括附加文件，例如图片，并必须将它们放在 ./assets/0000-my-new-standard/ 中。以下所有部分都是必填的。
头部
包含一些 TEP 属性：TEP ID 和拉取请求链接、标题、状态、类型、作者、替代的 TEP 链接和被替代的 TEP 链接。
正文
- 摘要
- 动机
- 指南
- 规范
- 缺点
- 理由和替代方案
- 先前艺术
- 未解决的问题
- 未来可能性
TEP 生命周期
草稿
作者准备 TEP 并向该仓库打开一个拉取请求。如果有必要，作者可以不启动审核过程，例如，如果有一些未解决的问题，必须在启动审核过程之前解决。然而，如果长时间没有活动，编辑可以关闭草稿状态的拉取请求。
审核
当 TEP 准备好时，作者必须通过将 TEP 状态更改为 Review 来启动审核过程。编辑检查拉取请求，然后由编辑指派审核者（作者或其他任何人可以提议将审核者指派给拉取请求）。审核者在拉取请求中分享他们的意见，如果讨论不在拉取请求中进行，他们必须在拉取请求评论中总结讨论。审核者必须投票赞成或反对提案。一旦大多数人同意，最终评论期开始，持续 10 个日历日。任何人都可以分享他们对该 TEP 的想法，如果有理由，编辑可以取消 FCP。在这种情况下，审核过程重新开始，审核者必须再次投票以完成拉取请求。当 FCP 结束时，编辑将 TEP 状态从 Review 更改为 Active 或 Rejected。
活跃
当 TEP 被审核者接受后，它变为活跃状态。为了使 TEP 与实际实施细节保持一致，可以对活跃的 TEP 进行小的更改。
拒绝
当 TEP 被拒绝时，相应的拉取请求不能被合并，而是可以被关闭。然而，保留拒绝的拉取请求是可以的，这样作者可以对 TEP 进行更改并再次申请审核，而不会失去之前的讨论。
被替代
在某些时候 TEP 可能会被弃用。当这种情况发生时，其状态变为被替代。还需要在 TEP 头部提供一些关于替代的信息：“替代”字段从新 TEP 指向旧 TEP，“被替代”字段从旧 TEP 指向新 TEP。
缺点
谁必须管理关闭拉取请求的过程？
存在审核者不会及时审核拉取请求的风险，因为没有明确的经理或产品负责人，审核者的动机也不明确。
理由和替代方案
部分列表 完全取自 Rust RFC。它激励作者在与社区开始讨论之前深入探讨 TEP 的论证。
RFC 822 头部 从 PEP/BIP/EIP/NEP 中被替换为 Rust RFC 头部，因为它有助于改善用户体验，提供 TEP 拉取请求和作者的链接。
在 NEP 中，提案在实际拉取请求合并和提案审核之前就已定稿。这不必要地复杂化了审核过程，因为作者不容易对已合并的拉取请求进行小修正。因此，为了简化所有事情，在 TEP 中整个审核过程保持在拉取请求中，因此很容易进行审核“乒乓”，作者在审核过程中进行快速修正以与社区达成共识。
先前艺术
未解决的问题
- 谁必须指派审核者？谁可以成为审核者？他们将如何证明自己的经验，谁将检查？
未来可能性
无