文档开发工具【免费下载链接】fig-standardsStandards either proposed or approved by the Framework Interop Group项目地址https://gitcode.com/gh_mirrors/fi/fig-standards点击查看免费下载本文基于 fig-standards 仓库治理章程 bylaws/001-mission-and-structure.md 展开系统讲解 PHP Framework Interoperability GroupPHP FIG的组织使命、治理层级会员项目、项目代表、核心委员会、秘书、工作组、维护者以及三类正式产出物PSR、PER、AR的界定。读完本文你将完整掌握 PHP FIG 如何通过一套公开、可投票、权责分离的治理机制驱动 PHP 生态标准的诞生与演进并能结合 personnel.md、PSR.md、PER.md 等仓库文件核验其实际运转情况。一、使命声明PHP FIG 是什么PHP Framework Interoperability GroupPHP FIG的使命是推动 PHP 生态进步并促进良好标准的形成——它将项目和开发者汇聚在一起进行协作基于真实世界的实践经验以及自身与他人的研究与实验开发并公开发布标准最终形成三类正式产物PHP Standard RecommendationsPSRPHP 标准建议PHP Evolving RecommendationsPERPHP 演进建议Auxiliary ResourcesAR辅助资源。仓库根目录的 README.md 对使命做了更朴素的表述项目代表们聚在一起讨论各自项目的共性寻找协作方式主要受众是彼此但也欢迎 PHP 社区其他成员自愿采纳其成果。二、会员项目Member Projects成员资格与申请流程2.1 资格要求依据章程FIG 会员项目Member Project必须是公开可获取的 PHP 项目或对 FIG 使命有重要意义的 PHP 利益相关组织已正式发布、有已知生产环境部署的项目而非愿景中的项目不强制要求实现任何特定 PSR但应当对相关 PSR 给予应有的考量。此外章程对依附型项目有明确排除条款仅作为另一个项目的扩展或插件而存在的项目不具备申请资格但项目可以复用其他项目的代码、库或框架而不因此丧失资格。当界限不清晰时由项目代表Project Representatives以最佳判断落实本条的精神。2.2 申请流程一个项目申请成为会员项目必须包含一位现任Project Representative 或 Core Committee 成员作为赞助人sponsor拟任Project Representative 的姓名对项目本身及其与 FIG 相关性的描述。申请发布后需经历至少两周的讨论期。讨论期结束后赞助人可发起Membership Vote会员投票。若投票通过项目即被认可为会员项目并指定其 Project Representative若未通过只要仍能找到赞助人项目可随时重新申请。2.3 退出与重新申请会员项目可通过向 FIG 官方公开渠道提交书面退出声明辞职声明发布并经秘书确认后该 PHP 项目立即停止作为会员项目前会员项目可在任何未来日期重新申请会员资格。仓库 personnel.md 的Former Member Projects列表中可以看到 Doctrine、Guzzle、Laravel、Symfony 等知名项目都曾是会员但已退出从侧面印证了退出与重新申请机制确实存在运转。三、项目代表Project Representatives投票权主体3.1 角色与任命所有会员项目的投票由被会员项目授权的Project Representatives行使。每位 Project Representative 完全由其所代表的会员项目单独选定无需 FIG 批准代表其项目的会员项目可在任何时候更换代表。3.2 数量与兼任限制一个会员项目同时最多只能有一名Project Representative任何个人不得同时代表多个项目一名 Project Representative 可同时担任 Core Committee 成员、PSR Editor 或 Working Group 成员但不得同时担任 Secretary秘书。3.3 投票权临时转授Project Representative 可将投票权或工作组资格临时转授给由其所代表会员项目授权的另一人。转授必须以书面形式通知 FIG并说明临时代表的姓名以及有效期。有效期结束时全部投票权自动归还原 Project Representative。3.4 驱逐投票Expulsion Vote若 FIG 判定某 Project Representative 行为不当、损害了 FIG 达成目标的能力任何 Core Committee 成员可发起Expulsion Vote要求更换该代表或在无法更换代表时驱逐其会员项目。此场景下被涉及的会员项目/代表不得参与投票被驱逐的会员项目须至少一年后方可重新申请被投票更换的代表无限期不得回归其当时所代表的项目或其他任何项目。关于 Expulsion Vote 的具体投票规则核心委员会 50% 法定人数、50% 多数项目代表无法定人数、50% 多数两方均通过方可批准详见 bylaws/004-votes.md。四、核心委员会Core Committee12 人决策董事会Core Committee 是一个由 12 名成员组成的董事会成员以技术技能与专业能力被认可。其核心职责包括就 FIG 将考虑哪些规范、批准哪些规范作出最终决定确保所有已发布规范具有高质量与一致性确保所有相关视角与使用场景得到应有的考量。兼任规则Core Committee 成员不得同时担任 Secretary可以但非必须同时担任 Project Representative但以 Core Committee 成员身份行事时应考虑其行为对整个 PHP 生态的影响核心委员会成员被期望对提交给 FIG 的所有议题保持积极关注。personnel.md 中列出的现任 Core Committee 成员如 Larry Garfield、Cees-Jan Kiewiet、Korvin Szanto 等任期横跨 2026—2027 年即为该 12 人制在实际中的体现成员的选举与任期安排见 bylaws/005-elections-and-vacancies.md两年任期、错峰选举、任期结束于当月最后一个周日的 17:00 UTC 等。五、秘书Secretaries中立管理员5.1 角色定位FIG Secretary 的首要职责是充当FIG 的中立管理员impartial administrator他们服务于会员项目与核心委员会但以独立、公正的裁决者身份行事同时代表 FIG 整体就 FIG 相关活动面向公众与社区发声。为保证公正性Secretaries不得兼任Project Representative、Core Committee 成员或 PSR Editor但可以成为 Working Group 成员且必须公开声明所有利益冲突例如参与工作组或是某会员项目的核心团队成员。5.2 定义职能Defined Functions章程明确列出了秘书需要完成的职能清单但可在其职责范围内承担其他必要职责管理官网websiteGitHub 组织与仓库管理计票与管理投票系统跟踪会员项目活动确保章程得到遵守解释章程文本若被三名及以上 Project Representative 或 Core Committee 成员质疑/反对必须付诸投票若秘书之间无法就解释达成共识也须进行完整投票确保相关营销渠道如 Twitter 和 Facebook保持专业、及时与中立在 GitHub、邮件列表、IRC 频道等官方沟通媒介上维持适当环境可限制发帖与施加禁言但不得永久封禁或限制 Core Committee 成员或 Project Representative在会议或其他临时聚会上做会议记录并回报邮件列表任期内实质上充当 PHP FIG 的Developer Advocates开发者布道者。5.3 访问权限与能力Access and Abilities秘书被授予 GitHub 组织Owners权限以及对官网、营销、沟通媒介域名、Twitter、IRC 频道、packagist.org 包、邮件列表等的完全admin管理权限秘书不是正式投票成员但有权发起任何投票无权投票为保障公正性一名秘书发起的投票必须由另一位秘书管理并计票。仓库 CONTRIBUTING.md 的Merge Access Policy与之呼应只有秘书拥有对所有仓库及 GitHub 组织的完全管理权限且章程类文件的合并只能由秘书执行。六、工作组Working GroupsFIG 工作的主战场6.1 总体机制FIG 的大部分工作由工作组承担在核心委员会的指导与支持下推进。工作组成员被期望积极参与。每个工作组有唯一一名 Editor编辑负责工作组任务的顺畅运转对工作组产出拥有最终权威由 Core Committee任命负责管理工作组开发、代表工作组与 FIG 其他部分沟通、协调其他贡献者任何人皆可担任 Editor前提是不得同时担任 Secretary若提案的 Editor 无通知缺席超过 45 天Core Committee 可协商任命新 Editor一名个人可同时担任多个工作组的 Editor。任何公众成员都可随时申请加入工作组由 Editor 判断其经验与视角是否对工作组开发有特别价值Editor 可在成员超过 30 天不活跃或对工作组顺畅运转造成干扰时将其移除。Project Representatives 或其指定代理也可随时申请加入Editor 若有异议可拒绝。6.2 完整工作组Full Working Group由一名 Editor 一名 Sponsor 至少三名其他成员组成Sponsor 必须是 Core Committee 成员Editor 与 Sponsor共同承担成员管理职责一名个人可同时担任多个工作组的 Sponsor其他 Core Committee 成员若愿意也可加入。6.3 有限工作组Limited Working Group由一名 Editor 至少两名其他成员组成不要求 Sponsor任何个人都可担任成员或 Editor唯一例外是Editor 不得同时是 Secretary。这一区分与 PER 工作流直接关联bylaws/003-per-workflow.md 规定 PER 默认成立Limited Working Group但 Core Committee 在涉及生态影响特别大的场景下可要求成立Full Working Group以鼓励更广泛的社区参与。6.4 工作组管理Working Group Management创建工作组由 Core Committee 的Entrance Vote进入投票创建该投票同时任命 Editor 及如适用Sponsor解散Editor及适用时 Sponsor可随时通知 Core Committee 任务完成工作组随即通过Implicit Approval默示批准解散必要时可举行 Decision Vote 任命新 Editor辞职Editor 或 Sponsor 可随时通过邮件列表通知 Core Committee 辞职若指明从工作组成员中挑选接替者该成员将立即通过默示批准继任失效解散工作组若连续 60 天缺失 Editor、连续 60 天缺失 Sponsor、连续 60 天活跃成员不足或连续六个月无任何活动迹象Core Committee 可举行 Decision Vote 任命新 Editor/Sponsor——该投票的选项之一必须包含解散工作组若找不到合适候选人工作组自动解散重建工作组解散后日后可通过新的 Entrance Vote 重建覆盖相同范围的新工作组资源秘书负责为工作组提供必要资源如专门的 GitHub 仓库、邮件列表、聊天室或类似工具。七、维护者Maintainers可演进产物的守护者7.1 责任与任命Core Committee 对 FIG 产出的所有制品负有最终责任但对于旨在随时间演进的制品Core Committee 可将该责任委托给一名 Maintainer。工作组的 Editor自动成为该工作组成果的 Maintainer其他 Maintainer 由 Core Committee 通过Approval Vote任命。Maintainer 可随时卸任并提名继任者经默示批准秘书负责确保 Maintainer 获得开发制品所需的访问权限与资源。7.2 演进制品与语义化版本可演进制品遵循Semantic Versioning语义化版本。若某个改动究竟属于 bugfix 还是 minor release 不明确Maintainer 将默认为 minor release。发布流程分级如下变更类型流程要求Bugfix 发布Maintainer 可随时发布制品新版本Minor 发布Maintainer 必须通过邮件列表发布Intent to Merge合并意向通知 Core Committee该意向受Implicit Approval默示批准约束必要时进行 Approval VoteMajor 发布必须经 Core Committee强制 Approval Vote强制批准投票关于 Implicit Approval 的具体机制发布意向后七天内无 Core Committee 成员反对即视为批准若有成员要求则转为正式投票见 bylaws/004-votes.md。PER 的发布流程1.0.0 之前的 alpha/beta/0.x 预发布不受 Core Committee 批准约束1.0.0 之后的 major 发布必须经 Core Committee 批准等在 bylaws/003-per-workflow.md 中有更详细的衔接。八、产出物PSR、PER 与 AR 三种制品章程将 FIG 的正式产出物划分为三类均受既有工作流章程约束此列表并非 FIG 可能从事的全部活动8.1 PSRPHP Standard Recommendation定义互操作标准在提供方providers与消费方consumers之间建立契约目标是鼓励或促进跨项目协作与标准化开发至特定终态后一旦批准即在时间上冻结frozen in time为实现者提供稳定可靠的目标——例外情况由 PSR Amendments 与 PSR Evolution 章程规定见 bylaws/007-psr-amendments.md已接受的 PSR 含义不可改变、向后兼容性必须保持 100%、原措辞引发的混淆只能通过 errata 澄清由工作组开发。仓库 PSR.md 展示了 PSR 的全景状态索引已接受Accepted如 PSR-1、PSR-3、PSR-4、PSR-6、PSR-7、PSR-11、PSR-12、PSR-14、PSR-16、PSR-18、PSR-20 等对应文件位于 accepted/、草案Draft如 PSR-5 PHPDoc、PSR-19 PHPDoc tags、PSR-21 国际化、PSR-22 追踪、已废弃Abandoned如 PSR-8、PSR-9、PSR-10以及已弃用Deprecated如 PSR-0、PSR-2。PSR 的完整生命周期Pre-Draft → Draft → Review → Accepted以及 Errata、Deprecated、Abandoned、Project Referendum见 bylaws/002-psr-workflow.md。8.2 PERPHP Evolving Recommendation是最佳实践、参考、指南、通用工具或支持工具的正式定义可随着 PHP 语言与生态的演进而持续演化由工作组开发。PER.md 显示当前唯一的 PER 是 Coding StyleEditorLarry GarfieldSponsorChris Tankersley其正式工作流Formation → Development → Pre-Releases → Releases详见 bylaws/003-per-workflow.md。8.3 ARAuxiliary Resources是与某个 PSR 或 PER 相关或提供支持的额外工具、代码库或示例典型例子包括PSR/PER 的通用部分实现、no-op 空操作实现、针对 PSR/PER 实现的测试工具等所有 AR 必须直接关联到一个或多个 PSR 或 PER由**维护者Maintainer**开发而非工作组。九、治理机制在仓库中的实况印证9.1 人事档案personnel.md该文件记录了当前与历任的组织成员是治理结构落地运行的直接证据SecretariesAlessandro Lai2017-11-12 起、Mark Niebergall2023-05-25 起、Lane Staples2024-02-25 起Core Committee 成员11 位现任成员任期大多在 2026—2027 年结束Member Projects包含 Composer、CakePHP、TYPO3、phpBB、Yii framework、ReactPHP、Slim、Hyperf、Joomla、Magento、PEAR 等 30 余个项目每个均列出其 Project Representative历届人员完整列出历任 Secretaries、历任 Core Committee 成员与历任会员项目如 Laravel、Symfony、Doctrine、Guzzle、Drupal 等与可随时退出并可日后重新申请的章程条款互相印证。9.2 标准索引PSR.md 与 PER.mdPSR 的 Accepted/Draft/Abandoned/Deprecated 四态索引及其 Maintainer/Editor/Sponsor 名单与 bylaws/002-psr-workflow.md 中的状态机一一对应PER 的表格展示了Editor Sponsor 版本发布的工作组配置印证了 bylaws/003-per-workflow.md 的角色设定。9.3 参与入口README.md 与 CONTRIBUTING.md提出新 PSRfork 本仓库 → 新建分支 → 将 PSR 放入proposed/→ 推送分支 → 发送 Pull Request或在 GitHub 建 ticket、在邮件列表发起讨论。注意 README 明确提示PSR 相关讨论一律在邮件列表进行GitHub 上的 issue/PR 极少被监控申请会员无需先成为投票成员即可参与讨论申请成员需向邮件列表发送邮件主题格式为Membership Request: {$your_name} ({$project_name})正文包含姓名、所代表项目名称与链接等信息由现任成员投票表决单个请求独立线程合并与访问策略Draft 与 Review 阶段规范的 Editor、Coordinator、Sponsor 拥有本仓库推送权限所有改动须经 Pull Request不得直接推送涉及已接受 PSR 的改动未经秘书批准不得合并章程改动仅能由秘书合并标签tag须由秘书创建并 PGP 签名许可代码贡献按 MIT 许可文档/示例等非代码资产按 CC BY 3.0 许可参见 LICENSE.md、LICENSE-MIT.md、LICENSE-CC.md。9.4 投票机制bylaws/004-votes.md章程中反复出现的 Entrance Vote、Readiness Vote、Acceptance Vote、Approval Vote、Decision Vote、Expulsion Vote、Recall Vote、Bylaw Vote 等其法定人数、多数门槛与投票窗口在投票章程中有统一约定默认投票期为两周或直至所有合格选民投票完毕明确弃权0计入法定人数但不计入多数法定人数与多数按四舍五入计算如 1/3 法定人数的 20/21/22 人选举区需 7 票23/24/25 人需 8 票50% 多数的 10/11 票需 6 票赞成12/13 票需 7 票赞成。这些规则直接支撑了 001-mission-and-structure.md 中描述的各类决策场景。十、结语一张权责分离的治理蓝图回顾 001-mission-and-structure.md 的完整设计PHP FIG 的治理体现了几个贯穿始终的原则共识与投票并存日常例行事务走 Implicit Approval默示批准争议事项走正式投票兼顾效率与公平权责分离Secretary 中立管理但不投票、Core Committee 最终决策、Editor 对工作组产出有最终权威、Sponsor 把关演进方向四者互不兼任关键冲突角色开放与可退出任何人可参与讨论与加入工作组项目可自由申请、退出与重新申请会员稳定与演进分层PSR 一经批准即冻结以保证实现者稳定PER 与 AR 则按语义化版本持续演进由 Maintainer 分级把关。这套结构最终将社区的真实世界经验转化为 PSR、PER 与 AR 三类可引用的正式产出——这正是 accepted/、proposed/ 目录下那些标准文档之所以值得信任的组织基础。对于希望理解 PSR 标准背后决策过程、或有意参与标准制定与维护的开发者而言从本文梳理的治理结构入手是最准确也最高效的起点。赞分享文档开发工具【免费下载链接】fig-standardsStandards either proposed or approved by the Framework Interop Group项目地址https://gitcode.com/gh_mirrors/fi/fig-standards点击查看免费下载相关推荐Apereo CAS 项目管理委员会PMC治理机制全解析成员结构、投票规则与提名流程Apereo CAS 项目管理委员会PMC治理机制全解析成员结构、投票规则与提名流程 Apereo CAS 作为一个由志愿者驱动的大型开源单点登录SSO后端认证鉴权单点登录人工智能伦理委员会章程模板完整条款与组织结构指南在人工智能技术飞速发展的今天建立专业的伦理委员会已成为企业和组织的必然选择。本文将为您提供一份完整的人工智能伦理委员会章程模板包含所有必要的条款和组织结构知识管理开发工具RedditVideoMakerBot开源治理委员会成员与职责RedditVideoMakerBot开源治理委员会成员与职责 你是否曾好奇一个能通过单命令生成Reddit视频的开源项目是如何高效运作的随着Reddit音视频工作流自动化上一篇TrollStore开发者模式终极指南iOS 16调试功能完全解析下一篇猫抓Cat-Catch使用指南3 步把网页视频下载存到本地创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考