提出新特性的新流程

你是否曾经好奇新功能是如何进入 Joomla 核心的？虽然过去 Joomla 一直遵循“先写代码，然后我们来看它并做出决定”的模式，但现在的 Joomla 有一个支持“先思考，再实施”策略的专业流程。

当许多贡献者提出一个功能或甚至为 Joomla 写了一个被拒绝的拉取请求，或者更糟糕的是被忽视时，他们感到非常沮丧。尽管某些功能从架构角度来看设计得很差，但它们仍然被整合到核心中，仅仅是因为我们不敢拒绝来自在项目中备受尊敬的人的贡献。这导致贡献者数量减少，代码库的可扩展性不如预期。

这必须改变，因此我们创建了一个 RfC 流程，具有明确的工作流程。任何人都可以提出功能。只需要两件事：功能的描述（摘要）以及为什么应该考虑它（为什么要费心？）。然后，提案将经过不同的阶段。

预-草稿

初步草稿阶段的目的是确定大多数 Joomla 是否对某个特定功能感兴趣。

任何对这个功能感兴趣的人都可以参与讨论。讨论发生在哪里无关紧要，只要对感兴趣的人开放即可。这包括在官方 Joomla 讨论媒体上关于这个想法是否合理以及是否在 Joomla 目标范围内的非正式讨论。

一旦这些方决定继续，他们就会成立一个工作组。工作组至少包括

• 一个编辑

• 生产部门团队领导，作为赞助商

• 至少另外一个人。这可以包括团队领导或团队成员以及普通社区成员。

在此阶段，建议不需要完全开发，尽管这是允许的。至少，它必须包括要解决的问题的解释、理由和一般方法的基本信息。进一步的修订和扩展预计只有在起草阶段才会进行。这是为了防止过多精力投入到采纳机会几乎为零的功能上。

社区或生产部门的团队领导（根据建议的具体性而定）将决定是否进一步推进该建议。

如果投票结果为正面，则建议正式进入起草阶段。该建议将被分配其自己的RfC编号。

工作组当然可以在投票期间继续对该建议进行工作。

起草

起草阶段的目标是讨论和精炼一个特性建议，使其达到生产部门团队领导可以审查的程度。

在起草阶段，工作组成员可以通过pull请求、GitHub上的评论、邮件列表、IRC以及类似工具进行他们认为适当的任何更改。这里的更改不受严格规则的限制，如果编辑支持，可以进行根本性的重写。任何时候都可以提出和讨论替代方法。如果编辑和赞助商确信替代提案优于原始提案，则替代提案可以替代原始提案。工作组成员在整个起草阶段应保持承诺。讨论是公开的，无论个人是否与Joomla有关联，都欢迎作出建设性的贡献。在此阶段，编辑对建议规范的更改拥有最终决定权。

生产部门协调员将确保工作组获得进行规范工作所需的必要资源，例如专门的GitHub仓库、邮件列表、论坛区域和类似工具。

在起草阶段获得的所有发现，例如可能的替代方法、其影响、优点和缺点等，以及选择建议方法的原因，必须在元文档中进行总结。本规则旨在防止讨论陷入僵局或替代提案在作出决定后再次出现。

如果编辑和赞助商同意提案已准备就绪，且元文档客观完整，编辑可以在工作组内进行准备投票，以确定规范是否基本完整，并准备进入下一阶段。

如果投票结果为正面，则建议正式进入审查阶段。如果不为正面，它将停留在起草阶段。

审查

审查阶段是社区尝试一个合理定义的目标以评估提案可行性的机会。在此阶段，赞助商是规范更改的最终权威，以及任何决定提案向前或向后推进的决定；然而，编辑可以否决他们认为会损害规范设计的提案更改。

现在只允许对规范的错误修复和编辑性更改（措辞、打字错误、澄清等）。此阶段不允许进行重大更改。如果明显需要重大更改，则规范必须移回起草阶段。任何需要对实现进行重大适应努力的不可兼容更改都视为重大更改。小到中等的不兼容更改不一定需要返回起草阶段。

如果提案未返回起草阶段，则必须在审查阶段至少保持四周，直到

• 定义了用户界面，并编写了功能RfC中建议的功能的（帮助）页面。

• 对于接口定义，可以展示两个独立的实际测试实现，理想情况下作为RfC仓库中的示例。寻找此类试验实现并将其展示给生产部门团队领导的责任在于工作组，特别是编辑和赞助人。由于并非所有规范都是PHP接口，其中“实现”的定义是显而易见的，赞助人应根据其知识判断何时是这种情况。生产部门团队领导的任何成员都可以以合理理由对某一特定试验实现提出异议，认为其与主题不相关或不足。

一旦过去四周，可以展示用户界面、帮助页面以及如果适用的话，两个可行的试验实现，赞助人可以要求进行接受投票。如果接受投票失败，规范仍处于审查阶段。

已接受

如果采用投票是积极的，该提议将正式成为接受的功能。在此阶段，工作组自动正式解散，但编辑（或指定的人员，该人员将被通知给生产部门协调员）在未来可能因打字错误、更改或规范错误而被要求做出贡献。

在功能RfC的情况下，生产部门内将组建一个开发团队，通常包括解散的工作组成员。

已实施

已实施的功能是已经开发、测试并合并到下一个可用的主要或次要版本的功能。

项目公投

在草案或修订阶段的功能编辑可以在任何时候要求生产部门团队领导对功能当前状态的非约束性公投。在功能进一步开发的过程中，可以多次进行此类公投。生产部门团队领导也可以将此类公投作为接受投票的条件。公投结果不具有约束力，但工作组和生产团队领导应充分考虑结果。