PHP-FIG 资金治理章程解读：010-funding 的募资、开销审批与超额资金分配机制

• 文档
• 开发工具

本篇技术指南以本仓库 bylaws/010-funding.md（PHP-FIG 章程第 010 号：Funding，资金）为骨架，完整梳理这一全由志愿者组成的组织如何围绕"公平、透明、公正"三大原则筹集、管理与支出资金。读完本文，你将掌握：PHP-FIG 唯一合法的募资渠道与展示要求、费用审批的投票流程与额度调整规则、超额资金（Overfunding）的计算公式与年度拨付机制，以及相关章程（如 004-votes.md 投票章程、001-mission-and-structure.md 使命与结构章程）如何相互咬合，共同约束组织的一切涉钱行为。

章程定位：为什么一个技术标准组织需要专门的资金细则

PHP-FIG（PHP Framework Interoperability Group，PHP 框架互操作组）是一个完全由无薪志愿者和社区成员组成的组织，其使命是推动 PHP 生态发展、制定并发布 PSR、PER 与 AR 等标准（见 001-mission-and-structure.md）。尽管组织本身不向任何人发工资，但它仍有持续性的小额运营开支——例如域名续费、邮箱账户等，这些都需要长期、稳定的资金来源。

010-funding 章程正是为这些涉钱事项立规矩的文档。它在章程体系中的特殊性在于：

• 唯一性：本文件"有意只描述允许的筹款、管理和花钱的唯一流程"，因此任何对这些流程的改动都必须走章程修订投票（Bylaw Vote）；
• 强制性：全文中大量使用 RFC 2119 / RFC 8174（即 BCP 14）定义的大写关键词——MUST / MUST NOT / REQUIRED / SHALL / SHALL NOT / SHOULD / SHOULD NOT / RECOMMENDED / NOT RECOMMENDED / MAY / OPTIONAL，语义严格按规范解释；
• 配套性：其规则落地依赖于 004-votes.md 中定义的 Approval Vote（批准投票）、Implicit Approval（默示批准）与 Bylaw Vote（章程投票）机制，以及 001-mission-and-structure.md 中定义的 Secretaries（秘书）与 Core Committee（核心委员会）角色。

财政托管（Fiscal Hosting）：资金必须经由 Open Collective

章程对"钱放在哪里"给出了硬性约束，不允许组织自建财务系统或私人账户收付款：

• PHP-FIG必须（MUST）使用 Open Collective 作为平台，并以 Open Source Collective 作为财政托管方（fiscal host）；
• 只有三位 Secretary（秘书）拥有 PHP-FIG OpenCollective 账户的完整管理权限，且不得（SHALL NOT）以自由裁量的方式使用这些权限，除非本章程明确授权；
• 所有资金必须归集到 Open Collective 的 PHP-FIG 账户中，从而让税务等合规问题由财政托管方自动处理；
• 每一项财务决策必须发布并公开，公开的载体有两个：本文档底部的对应表格，以及 Open Collective 的预算工具。

这一设计与 001-mission-and-structure.md 中对秘书角色的定位一脉相承：秘书的核心职责是"公正的管理员"（impartial administrator），负责管理网站、投票统计、保障章程被执行等行政事务。财务权限集中授予秘书而非 Core Committee 成员，正是为了在"管钱"这件事上保持行政中立、避免利益关联。

募资规则（Raising Money）

总体原则：主动募捐被禁止

PHP-FIG不得（SHALL NOT）向任何一方主动募捐，尤其是不得向个人主动募捐。所有例外必须明确列在本章程中。也就是说，组织只能"被动接受"符合规则的自愿贡献，任何主动拉赞助、众筹营销、向个人索捐的行为都在禁止之列。

经由 OpenCollective 的合规募资要求

贡献应当（SHALL）通过 Open Collective 接受，且页面配置必须满足两组硬性要求：

其一，描述文案（description）必须包含以下内容：

1. 指向 PHP-FIG 网站上本文档的链接（即本文所解析的 010-funding 章程原文 bylaws/010-funding.md）；
2. 声明"我们更希望收到来自公司的贡献，而非个人贡献"；
3. 声明"捐赠不赋予任何权利，也不对应任何服务"；
4. 如果本文档列有更适合个人的替代贡献途径，则给出这些链接；
5. 如果本文档列有超额资金接收方（overfunding recipients），则列出该清单。

其二，页面必须配置展示以下信息：

1. 贡献者名单及各自贡献金额；
2. 募得资金总额；
3. 已支出总额；
4. 账户剩余总额；
5. 逐笔交易明细，包含日期、金额与描述。

这组要求把"透明"落到了可操作的层面：任何人都可以随时核验 PHP-FIG 收了多少钱、花了多少钱、剩了多少钱，每一笔都对应到具体日期和用途。

支出规则（Spending Money）

资金用途红线：仅限非人事运营开支

捐赠给 PHP-FIG 的资金必须（MUST）仅用于非人事运营开支。PHP-FIG不得（MUST NOT）向任何个人贡献者或人员付款，包括 Core Committee 成员、Secretaries、Project Representatives 或工作组成员——唯一的例外是"与已批准开支相关联的报销"，例如某位 Secretary 自掏腰包垫付了一笔已批准的开支后，可以据此获得报销。

开支审批流程：Core Committee 批准投票

任何开支必须（MUST）经过 Core Committee 的Approval Vote（批准投票）。按照 004-votes.md 的定义，Approval Vote 是一个"是/否"问题：只有 Core Committee 成员可以投票，选项为 For（+1）/ Against（-1）/ Abstain（+0），法定人数（quorum）为 50%，通过需 2/3 多数。开销申请必须注明：

• 是一次性还是经常性（recurring）开支；
• 若是经常性开支，须写明发生频率；
• 必须论证该开支对 PHP-FIG 使命的贡献，即"这笔钱为什么非花不可"。

额度调整：10% 以内的默示批准通道

对于此前已获批准的经常性开支，如果供应商价格变动导致需要提高已批准的额度，Secretaries可以（MAY）向 Core Committee 请求Implicit Approval（默示批准）来调高额度，但前提是增幅不超过 10%。Implicit Approval 的机制见 004-votes.md：个人先声明"Intent to take an action"，若七天内没有任何 Core Committee 成员反对，该行动即视为获批；若有人反对，则转为正式的 Approval Vote 或 Decision Vote。这条通道让小幅涨价不必每次都走完整投票，同时 10% 的上限保证了审批权的实质可控。

所有经 Core Committee 批准的开支必须列在下方（见"已批准开支"一节），并同步上报到 Open Collective 预算中。

超额资金（Overfunding）与拨付机制

定义与计算公式

Overfunding（超额资金）被定义为：超出"覆盖 PHP-FIG 未来三年年度开支（按 '已批准开支' 一节核定）并按每年 10% 成本增幅递增"所需的资金。章程给出了一个示例：

若已批准预算为 $10，那么在资金被视为超额之前，可保留的最大金额为$10 + $11 + $12.1 = $33.10。

也就是说，安全水位 = 年度总开支 ×3.31（向上取整）。这个倍数的推导：第 1 年为1.0，第 2 年为1.1，第 3 年为1.1² = 1.21，三者之和恰好为 3.31。章程明确提示："需要保留的资金额度很容易计算——把年度总开支乘以 3.31 后向上取整即可。"超过该水位即构成超额，必须进入拨付流程。

年度审查与拨付

每年1 月，Secretaries应当（SHALL）审查 Open Collective 账户，并将任何超额资金按"已批准拨付接收方"一节中规定的对象与比例进行拨付。拨付方式必须（MUST）设计成不会给 PHP-FIG 或接收方带来额外税费或手续费的形式，章程点名的典型做法是 Collective to Collective Donations（Collective 之间的捐赠）。

如果因故无法向某个接收方拨付，则该接收方必须被跳过，且必须通知 Core Committee，以便本章程据此更新。

已批准拨付接收方（Approved disbursement recipients）

截至当前仓库版本，超额资金的唯一接收方是PHP Foundation（PHP 基金会），拨付比例为 100%。接收方清单仅此一条，且与"已批准开支"一节相同，享有与 Votes 章程（004-votes.md）不同的例外处理：

作为 Votes 章程的例外，对本章程这两个节（拨付接收方、已批准开支）的修改不应（SHOULD NOT）触发 Bylaw Change Vote（章程修订投票），而只需 Core Committee 的Approval Vote即可。

换言之，加一个接收方、调一个比例这类事务性变更，走 2/3 多数的 Core Committee 批准投票即可，不必动用门槛更高、需要 Core Committee 与 Project Representatives 双通道并发投票的 Bylaw Vote——后者按 004-votes.md 要求两方各需 2/3 多数。这样既保持了流程敏捷，又确保组织章程正文的严肃性不受琐碎修订的干扰。

已批准开支（Approved expenses）：章程中的实际预算账本

该节按时间顺序记录了 Core Committee 的预算决策（经常性或一次性），是观察 PHP-FIG 真实运营成本的窗口。当前仓库版本中登记的条目如下：

可以确认，PHP-FIG 的日常硬性成本全部来自域名与邮箱这类基础设施类非人事开支，总额仅 $48/年，这与其"无薪志愿者组织"的定位完全吻合。这两条记录也直接支撑了上文的超额资金测算：以 $48/年（按 10% 年增幅滚动三年）计算，安全水位约为$48 × 3.31 ≈ $158.88，超出部分即属超额资金、应按年度拨付给 PHP Foundation。

与其他章程的联动关系

010-funding 不是孤立的文件，它与仓库bylaws/目录下的其他章程构成一个可运行的治理闭环：

• 004-votes.md：提供 Approval Vote（50% 法定人数、2/3 多数）、Implicit Approval（7 天无异议即通过）、Bylaw Vote（双通道各 2/3）等所有被 010-funding 引用的投票原语；
• 001-mission-and-structure.md：定义 Secretaries 与 Core Committee 的角色边界，解释"为何只有秘书能碰钱"以及"为何开支审批权在 Core Committee"；
• 002-psr-workflow.md与003-per-workflow.md：规定 PSR/PER 的产生流程，让读者理解 PHP-FIG 的主要"产出"是标准文档而非商业服务——这也正是"捐赠不附带任何权利与服务"声明的业务基础；
• 100-implementation.md：FIG 3.0 章程改版时的过渡条款，属于历史性实施说明。

实践要点速查

• 想向 PHP-FIG 捐款：只能通过其 Open Collective 页面进行，页面上必须能看到贡献者名单、总额、已支出、余额与逐笔明细；捐赠不附带任何权利与服务；
• 组织侧花钱：任何开支须先经 Core Committee 的 Approval Vote 批准（50% 法定人数、2/3 多数），注明一次性或经常性及频率；已批准经常性开支的涨价额度调整走 Implicit Approval，且增幅不得超过 10%；
• 算超额：安全水位 = 年度已批准开支总额 × 3.31（向上取整），对应未来三年、每年 10% 的滚动增幅；每年 1 月由 Secretaries 审查并按表拨付（当前唯一接收方为 PHP Foundation，比例 100%）；
• 改规则：修改 010-funding 正文流程需 Bylaw Vote；但仅修改"拨付接收方"或"已批准开支"两个表，只需 Core Committee 的 Approval Vote；
• 查证：所有决策记录都在 Open Collective 预算工具与本文档底部的两张表中公开可查。

总而言之，010-funding 章程用最少的规则覆盖了"收钱—管钱—花钱—分钱"的完整资金生命周期：以 Open Collective + Open Source Collective 的托管结构解决合规问题，以秘书独享管理权限解决权力分散问题，以 Core Committee 批准投票 + 10% 默示调额解决审批与效率的平衡问题，以 3.31 倍水位公式 + 年度拨付解决资金沉淀问题。这套治理设计与其说是财务制度，不如说是把"透明、公平、公正"三原则翻译成了一组可执行、可审计、可自动化的规则——对于任何想要建立开源治理资金体系的社区，都是一份极佳的参考蓝本。

• 文档
• 开发工具