withastro/roadmap

# Astro 项目路线图 ## 概述 - [术语表](#glossary) - [阶段 1：提案](#stage-1-proposal) - [阶段 2：已接受的提案](#stage-2-accepted-proposal) - [阶段 3：RFC 与开发](#stage-3-rfc--development) - [阶段 4：发布！](#stage-4-ship-it) ## 术语表 ## 阶段 1：提案 **目标：** 围绕对 Astro 的想法和改进进行非结构化、低门槛的对话。有助于收集早期反馈，并与社区和维护者评估兴趣。 **要求：** 无需任何条件！要提出改进建议，请使用我们的（完全可选的）[提案模板](stage-1--discussion-template.md?plain=1) [创建一个新的讨论](https://github.com/withastro/roadmap/discussions)。 **位置：** GitHub Discussions [（查看所有开放提案）。](https://github.com/withastro/roadmap/discussions) Astro Discord 频道 `#feedback-ideas` 也可用于抛出想法以获取快速初步反馈，但请注意聊天记录短暂，不适合长期讨论。 ## 阶段 2：已接受的提案 **目标：** 与 Astro 维护者和技术指导委员会 (TSC) 确认提案的可行性。 **要求：** 一个现有的提案（阶段 1）。此外，如果提案详细且经过深思熟虑，能展示社区兴趣，至少有一名负责人志愿者，有一名维护者（L2+）担任负责人，并且得到了 Astro 维护者的支持/兴趣，则该提案更有可能被接受。 **位置：** GitHub Issues [（查看所有已接受的提案）。](https://github.com/withastro/roadmap/issues) **预期情况：** 提案在此阶段（即“被接受”）期间，会与维护者和 TSC（>= L2）在 [#rfc-meetings](RFC Meeting) 中进行，遵循我们现有的 [RFC 投票](https://github.com/withastro/.github/blob/main/GOVERNANCE.md#voting-rfc-proposals) 流程。 当提案被接受时，维护者（L2+）将创建一个新的 GitHub Issue，使用我们的官方模板总结原始提案。 提案的原作者将有机会自愿成为其负责人。如果他们拒绝，其他人可以通过在 GitHub Issue 中发帖自愿担任该职位。已接受的提案将保持为一个开放的 Issue，直到负责人由 TSC 确认。一旦确认，负责人可以自由地将提案推进到下一阶段。 在某些情况下，如果提案已知不可行或与项目的某些现有目标/使命相悖，TSC 可能会明确拒绝该提案。如果明确拒绝，TSC 成员将在提案上评论，解释拒绝的理由。 过时的、已接受的提案可以随时按照相同的现有 [RFC 提案](https://github.com/withastro/.github/blob/main/GOVERNANCE.md#voting-rfc-proposals) 投票流程被移除（即在之前接受后被拒绝）。 ## 阶段 3：RFC 与开发 **目标：** 开始开发！在开发过程中收集实施反馈并与维护者合作。 **要求：** 一个已接受的提案（阶段 2）以及一位负责撰写和实施 RFC 的提案负责人。 **位置：** GitHub Pull Requests [（查看所有进行中的 RFC）](https://github.com/withastro/roadmap/pulls) [（查看所有已完成的 RFC）](https://github.com/withastro/roadmap/tree/main/proposals) **预期情况：** 要为一个已被接受的提案创建 RFC，提案负责人必须使用仓库中的 [`stage-3--rfc-template.md`](stage-3--rfc-template.md?plain=1) RFC 模板。RFC 模板的初始部分应从已接受的提案中复制粘贴（它们是一一对应的）。所有剩余部分留给负责人完成，填写 RFC 的实施和权衡细节。 当阶段 3 的 RFC 被创建时，阶段 2 的 RFC 应关闭，并附上一个指向阶段 3 RFC Pull Request 的链接评论。 您无需在开始开发前获得 RFC 批准！验证 RFC 的最佳方法之一是制作原型，因此强烈鼓励早期原型开发和与 RFC 并行进行开发。RFC 在此阶段是一个动态文档，在构建过程中对收集反馈最有用。RFC 将在其对应的 PR 也准备好合并时才会被接受和合并。 提案负责人可以在任何时候请求对其 RFC 的反馈，无论是在 Discord 中异步进行（在 `#dev`/`#dev-ptal` 频道内），还是在我们的每周社区电话会议中。维护者应在此阶段提供及时的反馈，以便 RFC 作者永远不会被阻塞。如果您是 RFC 负责人并且需要访问 `#dev-ptal` 频道，请联系 **@fks** 获取权限。 ## 阶段 4：发布！ 当 RFC 的 Pull Request 准备好进行最终审查时，RFC 就准备好被批准和定稿。当负责人认为 RFC 准备就绪时，可以要求进行共识征询。 此时，核心团队的某位成员将动议进入最终评论期 (FCP)。这遵循我们现有的 [RFC 提案](https://github.com/withastro/.github/blob/main/GOVERNANCE.md#voting-rfc-proposals) 投票流程。最终评论期结束后，如果没有异议，RFC 将被合并。 ## RFC 会议 RFC 在与 TSC 和维护者的 RFC 会议中推进各个阶段。投票遵循 [RFC 提案](https://github.com/withastro/.github/blob/main/GOVERNANCE.md#voting-rfc-proposals) 投票流程。 会议是非定期、临时召开的。当提案作者或负责人认为准备好进入下一阶段时，就会召集会议。作者或负责人可以通过联系 TSC 安排时间来请求召开会议。 所有维护者都被邀请参加会议。如果达成共识，RFC 将推进到下一阶段。完整详情请参阅 [RFC 提案](https://github.com/withastro/.github/blob/main/GOVERNANCE.md#voting-rfc-proposals) 文档。 **先例 / 特别感谢** 此流程融合了 [Remix 的开放开发流程](https://remix.run/blog/open-development) 和我们之前的 [RFC 流程](https://github.com/withastro/roadmap/blob/78b736c28fe487ad02ec76bb038ad1087c471057/README.md)，而之前的流程是基于 Vue、React、Rust 和 Ember 项目的 RFC 流程。

标签：Astro框架, CMS安全, Discord, DNS解析, JavaScript, Linux 内核安全, RFC流程, SEO优化, TypeScript, Web前端, 安全可观测性, 安全插件, 开发流程, 开源项目, 技术路线图, 提案管理, 版本控制, 社区协作, 网络安全研究, 讨论平台, 软件开发, 防御加固, 静态站点生成, 项目管理