治理、RFC 与社区
Pling 目前由维护者主导。本页说明当前如何决策、如何提出协议变更，以及参与项目时需要遵守哪些边界。它不描述一个尚不存在的基金会、委员会或选举机制。
当前决策方式
- 项目在 GitHub 上公开维护。
- 一个较小的维护者小组负责代码评审、发布、安全协调和协议发布。
- 小型文档修复和边界明确的缺陷可以在 pull request 中决定。
- 能力语义、协议消息、授权边界或公开 API 契约的变化，需要书面理由、兼容性分析、测试和迁移说明。
- 安全修复可以在私下准备，直到用户有合理时间升级。
项目规模仍然很小时，不会把自己描述成独立治理机构。治理声明应由实际做法支撑，而不是先于做法出现。
如何提出协议变更
先开 issue 描述问题，再提交实现或规范修改。一个可评审的提案至少回答：
- 对页面、客户端、网关或独立实现而言，哪一项可观察行为发生变化？
- 这是澄清、增量变更、破坏性变更，还是安全修复？
- 哪个版本标识改变？旧客户端如何失败关闭？
- 哪些测试同时证明新行为与拒绝行为？
- 运营方如何迁移，同时不扩大访问范围、不丢失审计关联？
- 某个实现无法立即升级时，回滚路径是什么？
参考实现能够运行，不足以让提案通过。协议正文、类型定义、错误注册表、一致性用例和迁移说明必须描述同一行为。
决定与记录
维护者在 issue 或 pull request 中记录决定和主要理由，包括拒绝原因。涉及安全的内容可以在修复窗口内保持私密；其余协议讨论应公开可查。
当前没有编号 RFC 档案，也没有独立的协议委员会。涉及公开行为的提案仍应走公开讨论和评审，不能用“尚未建立正式流程”作为未记录变更的理由。
当项目增加技术指导或治理机构时，应在对外描述之前公开成员、产生方式、任期、决策范围和退出机制。目前尚未建立这类机构。
维护职责
在代码评审、文档、互操作或安全工作中持续做出高质量贡献的人，可以被授予维护职责。新增维护角色应公开姓名、范围和理由，让权限可以被检查，而不是只能从仓库权限中猜测。
维护职责不是对某个组织或商业关系的认可。技术判断仍应依据可复现的证据、兼容性后果和安全边界。
利益冲突
维护者、评审者和提案作者应披露可能合理影响协议决定的财务、雇佣或商业利益。存在实质冲突的人不应成为该提案的唯一决定者。披露与回避应记录在相关评审中。
这条规则同样适用于模型服务商、托管商、自动化厂商和客户组织。技术证据的权重高于提出者的职位或商业地位。
安全报告
不要在公开 issue 中披露可利用细节、真实凭证、客户数据或私有提示词。请通过仓库的 Security → Report a vulnerability 私下报告，具体边界见安全与信任中心。
参与贡献
- 修改公开行为、协议语义、安全边界或包结构前，先开 issue。
- pull request 应保持聚焦；行为变化需要测试，并同步更新对应参考页或教程。
- 说明兼容性与失败行为，而不只展示成功路径。
- 除非文件另有说明，仓库贡献按 Apache-2.0 接受。
- 项目不承诺固定响应时间或必定接受贡献。
社区行为
参与讨论应具体、基于证据并保持尊重。骚扰、歧视、披露私人数据，以及施压要求弱化安全边界，都不被接受。维护者可以关闭或移除违反这些要求的贡献，并在不造成安全风险时说明理由。
协议分歧是正常的。应批评主张、证据和兼容性后果，不应把评审变成围绕机构或身份的竞争。