文档开发工具【免费下载链接】fig-standardsStandards either proposed or approved by the Framework Interop Group项目地址https://gitcode.com/gh_mirrors/fi/fig-standards点击查看免费下载导读本指南以 bylaws/003-per-workflow.md 为核心骨架系统讲解 PHP Framework Interoperability GroupPHP FIG中演化推荐PHP Evolving Recommendation简称 PER从组建工作组、开发、预发布到正式发布的完整生命周期并结合 bylaws/001-mission-and-structure.md、bylaws/004-votes.md 等配套章程与 PER.md 索引展开。读完本文你将掌握 PER 与 PSR 的本质区别、各阶段角色Editor / Sponsor / Maintainer的权责、Entrance Vote 与 Readiness Vote 等投票机制以及一个 PER 从创意到 1.0.0 乃至后续 minor / major 版本发布所必须经过的全部关卡可直接对照仓库原文参与或发起一次 PER 提案。一、PER 是什么与 PSR 的关键区别在进入工作流程之前先明确 PER 的定位。根据 bylaws/001-mission-and-structure.md 的 Artifacts 一节PHP FIG 产出三类主要制品PHP Standard RecommendationPSR定义提供方与消费方之间的契约contract开发到特定终态后即被冻结为实现者提供稳定且可靠的目标除非符合 PSR Amendments / PSR Evolution 章程中的特定例外否则不再变化。PHP Evolving RecommendationPER对最佳实践、参考、指南、通用工具或支撑工具的正式定义。它们会随着 PHP 语言与生态的发展而持续演化同样由 Working Group工作组开发。Auxiliary ResourcesAR与某个 PSR 或 PER 直接相关的附加工具、代码库或示例如no-op实现、测试工具由 Maintainer 开发。PER.md 对 PER 给出了更精炼的定义A PHP Evolving Recommendation is a meta document accompanied by one or more artifacts that are set to evolve over time with multiple releases——PER 是一个元文档meta document外加一个或多个会随多个版本持续演化的制品。这正是与一经批准便冻结的 PSR 最根本的区别PSR 追求稳定契约PER 则允许制品随语言演进迭代。从仓库现状看PER.md 中已登记的 PER 为Coding StyleEditor 为 Larry GarfieldSponsor 为 Chris Tankersley它是 PSR-12 编码风格指南见 accepted/PSR-12-extended-coding-style-guide.md向可演化方向延续的产物也是理解 PER 工作流最直观的现实案例。二、工作流总览四个阶段的权责地图bylaws/003-per-workflow.md 将 PER 的生命周期划分为四个阶段每个阶段都有明确的触发条件、参与者与投票门槛阶段目标关键角色关键动作 / 投票Formation组建判断 FIG 多数成员是否对拟议概念感兴趣发起方、Editor / Sponsor、Core Committee非正式讨论 → 组建工作组 →Entrance VoteDevelopment开发协作打磨提案与制品Editor最终权威、工作组全体、公开社区PR / 邮件列表 / 聊天维护 meta 文档Pre-Releases预发布在 1.0.0 前放出不稳定版本Editor随时发布 alpha / beta / 0.x无需 Core Committee 批准Releases发布发布 bugfix / minor / major 版本Editor兼任 Maintainer、Working Group、Core Committeebugfix 直接发布minor / major 需Readiness Votemajor 需 Core Committee 批准下文按此骨架逐一展开。三、Formation从创意到 Entrance Vote3.1 兴趣确认与非正式讨论Formation 阶段的目标是判断 PHP FIG 的多数成员是否对某个拟议概念感兴趣、值得为其建立 PER 工作组。感兴趣的一方可以通过任何他们认为合适的方式讨论可能的提案包括可能的实现这包括在 FIG 官方讨论渠道上非正式地讨论该想法是否有价值、是否在 FIG 的目标范围内。此阶段的提案不要求完整成型当然允许已经成型但至少必须包含三要素要解决的问题陈述statement of the problem to be solvedPER 工作组的范围scope of the PER Working Group预期产出的制品the artifacts it expects to produce。这比 PSR 的 Pre-Draft 阶段要求更明确——对比 bylaws/002-psr-workflow.md 可见PSR 提案只需问题陈述 大致方法而 PER 额外要求声明范围与产出制品反映了 PER多个制品随版本演化的形态。3.2 组建工作组Limited 还是 Full一旦相关方决定推进他们必须组建一个工作组。默认形式是Limited Working Group有限工作组但Core Committee 可以要求某个特定 PER 使用 Full Working Group完整工作组条件是该 PER 对更大生态的影响特别大——其目的是鼓励更广泛的社区参与。两种工作组的构成在 bylaws/001-mission-and-structure.md 中有明确规定Full Working Group由一名 Editor、一名 Sponsor 以及至少三名其他成员组成。Sponsor 必须是 Core Committee 成员Editor 与 Sponsor 共同承担成员管理职责。Limited Working Group由一名 Editor 和至少两名其他成员组成不需要 Sponsor任何人均可担任 Editor 或成员Editor 不得同时是 Secretary。两种工作组均由 Core Committee 的Entrance Vote创建该投票同时包含 Editor 的任命以及如适用Sponsor 的任命。3.3 Entrance Vote进入 Draft 的关口对于 Limited Working Group 由Editor、对于 Full Working Group 由Sponsor召集一次 Core Committee 的Entrance Vote入口投票以询问 Core Committee 是否总体上有兴趣为该主题维护一个 PER——即便他们不同意提案的细节。这是一个方向性而非细节性的投票。Entrance Vote 的具体程序由 bylaws/004-votes.md 定义由 Sponsor 召集遵循 Approval Vote 程序。而 Approval Vote 的核心规则见 bylaws/004-votes.md为仅 Core Committee 成员投票选项为 For1、Against-1或 Abstain0法定人数quorum为 50%通过需要2/3 多数所有投票默认持续两周或直到所有合格投票者投完票以先到者为准投票公开明确弃权0计入法定人数但不计入多数。3.4 进入 Draft若 Entrance Vote 通过提案正式进入Draft 阶段并被赋予一个唯一的描述性名称例如 Coding Standards、Documentation 等。与 PSR 使用数字编号见 bylaws/002-psr-workflow.md 及 PSR.md 的数字索引不同PER 以名称标识这与其持续演化、不冻结的定位一致——名称不会像编号那样因版本迭代而语义模糊。四、Development公开协作与 meta 文档4.1 协作方式与公开性工作组一旦成立可以以任何他们认为合适的方式协作pull requests、GitHub 评论、邮件列表线程、实时聊天等等。讨论全程公开无论是否与 FIG 有关联任何人都欢迎提供建设性意见。这一点与 PSR Draft 阶段的规则一致见 bylaws/002-psr-workflow.md但 PER 的 Development 阶段更强调制品随版本演化这一前提下的持续打磨。4.2 meta 文档强制产出物Development 阶段的一个硬性要求是工作组必须维护一份meta 文档meta document其中必须包含考虑过但被拒绝的方法considered but rejected approaches各项决策的原因the reasons for various decisions以及 Development 过程中积累的知识。meta 文档被视为工作组产出的一部分必须与工作组的主要制品一同打标签tagged。这一规则的目的与 PSR 工作流一脉相承——bylaws/002-psr-workflow.md 明确指出记录替代方案及其利弊、选择当前方案的原因是为了防止已经拍板决定的方案重新引发循环讨论。仓库中现成的范本是 accepted/PSR-12-extended-coding-style-guide-meta.md它记录了 PSR-12 的缘起Why Bother、范围与非目标、Approaches严格类型声明为何被判定超出编码风格指南范围、为何强制类型关键字短形式等、对 142 名受访者含 17 名项目代表的公开调研结果、从 PSR-2 的变更清单以及 PeopleEditor / Sponsor / WG 成员和 Votes 记录。这正是meta 文档 决策依据 过程透明的完整实现PER 工作组的 meta 文档可以照此组织。4.3 Editor 的最终权威在 Development 阶段Editor 对工作组产出所做的任何更改拥有最终权力final authority。结合 bylaws/001-mission-and-structure.md 可知Editor 由 Core Committee 任命负责工作组使命的顺利运转、代表工作组与 FIG 其他部分沟通、协调其他贡献者任何人只要不是 Secretary都可以担任 Editor。若 Editor 无故缺席超过 45 天Core Committee 可以协商任命新 Editor。在 PER 语境下Editor 通常也是该 PER 的主导贡献者与作者见 PER.md。五、Pre-Releases1.0.0 之前的不稳定版本在 PER 的 1.0.0 发布之前Editor 可以在任何时间发布任意制品的 alpha、beta 或 0.x 版本。这些版本明确不稳定必须被视为不受 FIG 或工作组支持unsupported不受 Core Committee 批准约束not subject to Core Committee approval。这一阶段的存在意义在于PER 的制品文本或代码在正式定版 1.0.0 之前需要生态反馈来验证方向而预发布版本为外部试用提供了合法渠道同时通过明确不支持的声明保护 FIG 与工作组的声誉避免把预发布质量当作承诺。六、Releases语义化版本下的三重关卡Release 阶段是 PER 工作流中最精细的部分其核心原则是越不稳定的版本越容易发布越重要的版本关卡越多且全程遵循语义化版本Semantic Versioning的 major / minor / patch 划分。6.1 bugfix 版本随时可发PER 制品的 Editor 可以在任何时间发布 bugfix 版本bugfix release无需任何投票。这与 bylaws/001-mission-and-structure.md 中 Maintainers 章节的规则一致对于属于 bugfix 发布的更改Maintainer 可以随时发布制品的新版本。在 PER 工作流中Editor 在制品发布后自然兼任 Maintainer 角色详见第七节。6.2 minor / major 版本Readiness Vote 前置对于根据语义化版本属于minor 或 major的新版本无论是文本还是代码Editor必须首先召集一次工作组的 Readiness Vote就绪投票。Readiness Vote 的规则来自 bylaws/004-votes.md由Editor召集仅 PER 工作组成员包括 Editor 与 Sponsor有投票权选项为 For1、Against-1或 Abstain0法定人数 50%通过需 2/3 多数。注意其与 Entrance Vote 的区别Entrance Vote 的投票主体是 Core Committee12 人见 bylaws/001-mission-and-structure.md而 Readiness Vote 的投票主体是工作组内部——它检验的是工作组自身是否认可这次新版本发布而非外部审批。6.3 Intent to ReleaseEditor 以 Maintainer 身份通知 Core Committee若 Readiness Vote 通过Editor 以 Maintainer 身份in capacity as Maintainer可向 Core Committee 通知发布意图Intent to Release具体程序按 Maintainers 章节执行见 bylaws/001-mission-and-structure.mdminor 发布Maintainer 必须通过邮件列表发帖向 Core Committee 告知 Intent to Merge合并意图该意图受Implicit Approval约束——即若七天内没有任何 Core Committee 成员反对则视为默示批准若有人要求投票则转为正式的 Approval Vote 或 Decision Vote见 bylaws/004-votes.md。major 发布受Core Committee 强制性的 Approval Vote约束。6.4 major 版本的强制审批从 1.0.0 起任何 major 版本都必须获得 Core Committee 的批准The Core Committee must approve any major releases from 1.0.0 onwards。这是 PER 工作流与 PSR 演化规则相呼应的安全阀bylaws/008-psr-evolution.md 允许 PSR 接口包通过合理升级路径发布包含破坏性变更的 major 版本但要求若升级路径迫使消费方/实现方同时维护多个版本以支持同一 PSR 的多个版本则视为升级路径过陡。PER 的 major 版本同样要以生态的可承受性为前提而 Core Committee 的审批正是把守这一前提的机构。七、角色对照Editor、Sponsor 与 MaintainerPER 工作流中三个角色权责最容易混淆这里对照 bylaws/001-mission-and-structure.md 与 PER.md 整理角色出现在哪个阶段核心权责Editor全程工作组运转负责人对工作组输出拥有最终权威Limited WG 中负责召集 Entrance VoteDevelopment 中负责把关变更Pre-Releases 中可随时放预发布Releases 中召集 Readiness Vote并以 Maintainer 身份发出 Intent to ReleaseSponsorFull WG 特有必须是 Core Committee 成员负责召集 Entrance VoteFull WG 情形协助 Editor 保证演化进程不脱轨见 PER.mdMaintainer制品发布后制品发布后 Editor 自动成为 Maintainer负责后续 bugfix 随时发布、minor 的 Intent to Merge受 Implicit Approval、major 的强制 Approval Vote亦可就任后指定替代者Implicit Approval值得注意的约束Editor 与 Sponsor 可以同时担任多个工作组的同类角色但任何人不得同时担任 Secretary 与 Editor/Sponsor/Maintainer见 bylaws/001-mission-and-structure.md这是为了保持治理的公正性。八、投票机制的细节汇总PER 工作流涉及的投票不止 Entrance Vote 与 Readiness Vote理解 bylaws/004-votes.md 的通用规则有助于把握全局通用默认值除非另有规定所有投票持续两周或直到所有合格投票者完成投票先到者为准投票公开明确弃权0计入法定人数但不计入多数非平凡投票前应有至少两周讨论投票在投票期结束前可随时更改。法定人数与多数的取整以 1/3 法定人数的 20~22 人选区为例需 7 票23~25 人则需 8 票50% 多数在 10~11 票投出时需 6 票12~13 票时需 7 票。Approval Vote仅 Core Committee 成员投票法定人数 50%通过需 2/3 多数。Entrance Vote、Acceptance Vote、Errata Vote、Deprecation Vote、Abandonment Vote 均遵循此程序。Readiness Vote仅工作组成员投票法定人数 50%通过需 2/3 多数。Implicit Approval例行事务若七天内无 Core Committee 成员反对即默示通过任何成员可在七天内要求转为正式投票。九、PER 与 PSR 工作流对照两条路径的分叉点将 bylaws/003-per-workflow.md 与 bylaws/002-psr-workflow.md 并排比较可以清晰地看到两种标准在同一治理框架下的设计取舍维度PSR002 号章程PER003 号章程生命周期Pre-Draft → Draft → Review → Accepted → Erratas → Deprecated / AbandonedFormation → Development → Pre-Releases → Releases编号 / 命名数字编号递增描述性名称如 Coding Standards工作组形式Full Working GroupLimited Working Group默认高影响场景可要求 Full WG提案最低要求问题陈述 大致方法问题陈述 范围 预期产出制品发布后状态冻结仅允许 errata见 bylaws/007-psr-amendments.md持续演化可多次发布 minor / major版本治理PSR 本身不迭代接口包按 bylaws/008-psr-evolution.md 走语义化版本制品全程走语义化版本Editor 可随时发 bugfix一个典型的生态事实是曾经作为 PSR 冻结发布的编码风格指南其延续形态正是以 PER 形态存在的 Coding Style见 PER.md 登记表——这恰好说明需要持续演化的内容如何从 PSR 的冻结模型迁移到 PER 的演化模型。十、发布后的延续命名约定与语义化版本PER 制品的命名与发布还受 bylaws/009-naming-conventions.md 约束对想要发布 PER 代码的人尤其重要代码若作为PER 或 Auxiliary Resource的一部分发布vendor 命名空间必须是FigComposer 包名必须是fig/package如fig/cache-util作为 PSR 发布则用Psr/psr/package如psr/log。接口后缀Interface、抽象类前缀Abstract、Trait 后缀Trait的命名规则同样适用。实现某个 PSR 或 PER 的包应在composer.json中声明provides键形如psr/package-implementation: 1.0.0。同时bylaws/001-mission-and-structure.md 规定演化制品遵循语义化版本若某次更改是否属于 bugfix 还是 minor 不清楚Maintainer 应假定为 minor 发布——这条保守原则与 PER 工作流中minor/major 需 Readiness Vote、major 需 Core Committee 批准的关卡共同构成了 PER 制品版本治理的完整闭环。结语PER 工作流的设计哲学纵观 bylaws/003-per-workflow.md 全文PER 工作流的设计哲学可以概括为三句话方向由 Core Committee 把关细节由工作组自治Entrance Vote 只问是否值得维护这个主题不问细节Development 阶段 Editor 拥有最终权威讨论完全公开。过程强制透明meta 文档是硬性产出物且必须随制品打标签确保每个决策都有据可查、杜绝循环争论。发布按风险分级bugfix 随时发、预发布不受限、minor 需工作组 Readiness Vote Core Committee 默示批准、major 必须 Core Committee 强制批准——发布关卡随破坏风险递增。对于任何想要在 PHP 生态中推动一项会随语言演化而迭代的标准的团队来说先读懂这份章程、再对照 PER.md 观察 Coding Style 的实际落地是掌握 PER 工作流最高效的路径。赞分享文档开发工具【免费下载链接】fig-standardsStandards either proposed or approved by the Framework Interop Group项目地址https://gitcode.com/gh_mirrors/fi/fig-standards点击查看免费下载相关推荐awesome-gpt-image-2 完整实战把 532 个案例变成稳定的 GPT-Image2 提示词生产线awesome gpt image 2 完整实战把 532 个案例变成稳定的 GPT Image2 提示词生产线 awesome gpt image 2 是一文档开发工具SIG Release Charter 全解Kubernetes 发布流程的范围、角色与治理机制SIG Release Charter 全解Kubernetes 发布流程的范围、角色与治理机制 SIG Release 是 Kubernetes 社区中负责开源治理文档研发协作Hive 仓库 PR 强制关联 Issue 的自动化治理机制pr-requirements 工作流从文档到源码的全解析Hive 仓库 PR 强制关联 Issue 的自动化治理机制pr requirements 工作流从文档到源码的全解析 本文以 docs/pr require人工智能AI Agent多智能体MCP 服务工具调用浏览器控制上一篇如何快速优化Windows字体显示BetterClearTypeTuner终极指南下一篇Daytona Git提交请求代码保存与版本创建创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考