OpenSandbox 治理机制解析CODEOWNERS 角色模型、OSEP 决策流程与维护者晋升规则【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandboxOpenSandbox 是一个安全、快速且可扩展的 AI Agent 沙箱运行时由生命周期服务端、execd/ingress/egress 运行时组件、Kubernetes 控制器和多语言 SDK 等多个子系统组成。本文基于仓库根目录的 GOVERNANCE.md 展开并结合 .github/CODEOWNERS、oseps/ 与 .github/workflows/ 等仓库实体说明该项目如何定义 Contributor / Maintainer / Project Maintainer 三级角色、如何在日常变更、组件级变更与跨切面变更之间划分决策权、如何通过 OSEP 流程管理重大设计以及维护者晋升的提名、投票阈值与上板机制。读完本文你可以理解在 OpenSandbox 中提交 PR、参与评审或推动重大设计时应遵循的完整协作与决策路径。治理目标与适用边界GOVERNANCE.md 开篇即声明该文档描述 OpenSandbox 当前的治理方式与技术决策如何产生目的是如实反映项目现行的开源开发实践并随着项目增长向更正式的治理模型演进。治理体系围绕五个目标设计对贡献者和用户保持开放日常决策务实高效技术方向公开透明对公共 API、运行时和安全敏感变更保持安全审慎在多组件、多维护者之间保持可持续性。治理文档的适用范围覆盖 OpenSandbox 仓库及其主要公共接口面具体包括范围仓库位置说明公共 API 与规范specs/沙箱生命周期、诊断、execd、egress 等 API 契约生命周期服务端server/Python 实现的沙箱生命周期管理运行时组件components/execd、ingress、egress、nodeagent 等Kubernetes 控制器kubernetes/控制器、Helm charts、CRD 与部署资产SDKsdks/Python、Go、JavaScript、C#、Kotlin 等语言 SDKCLI、示例与文档cli/、examples/、docs/命令行工具、示例与项目文档项目价值观文档要求维护者与贡献者的行为始终符合五项原则公开开发设计讨论、issue 跟踪、代码评审尽可能在公开场合进行、兼容性意识公共 API、SDK、CLI 行为和已文档化的用户工作流不应随意变更、安全优先影响隔离、网络、凭据或执行安全的变更需要额外审视、组件所有权与跨项目问责子系统维护者拥有各自领域跨切面变更需要更广泛的评审、文档与实现一致公共契约、代码、SDK、示例与文档应保持同步。这些原则在仓库中有直接的落地形态。例如 specs/AGENTS.md 明确要求将specs/目录下的规范文件视为公共接口的 source of truth 并优先采用增量式变更且当契约变更影响下游时必须同步阅读 server/AGENTS.md、sdks/AGENTS.md 及components/下的组件文档这正是文档与实现一致原则的工程化体现。三级角色模型Contributor、Maintainer 与 Project MaintainerContributor任何参与项目的人都算贡献者包括开 issue 或讨论、提交 PR、评审代码、改进文档/测试/示例/工具链。贡献者需要遵循 CODE_OF_CONDUCT.md、CONTRIBUTING.md漏洞上报则走 SECURITY.md 的私密报告通道——从 SECURITY.md 的内容看漏洞应通过 GitHub Private Vulnerability Reporting 提交而非公开 issue。Maintainer以 CODEOWNERS 为公开记录Maintainer 是被授权在仓库一个或多个部分评审与引导变更的贡献者。文档明确指出当前子系统维护者身份的公开记录就是 .github/CODEOWNERS 文件某一路径的 code owner 即该领域的默认维护者。查看实际的 CODEOWNERS 可以看到该映射关系的具体内容规则自上而下求值、最后一条匹配生效# Default owners (fallback for files not matched by specific rules) * jwx0925 hittyt Pangjiping ninan-nn # Control plane (server) /server/ Pangjiping hittyt jwx0925 Generalwin ninan-nn # Runtime components /components/execd/ Pangjiping hittyt ninan-nn /components/ingress/ Pangjiping hittyt Generalwin Spground /components/egress/ Pangjiping hittyt jwx0925 # Kubernetes controller /kubernetes/ Spground Generalwin fengcone kevinlynx ninan-nn hittyt Pangjiping # SDKs /sdks/ ninan-nn jwx0925 hittyt Pangjiping # Specs and docs /specs/ jwx0925 hittyt ninan-nn # OpenSandbox Enhancement Proposals /oseps/ Spground Generalwin fengcone kevinlynx Pangjiping ninan-nn jwx0925 hittyt也就是说改components/execd/的 PR 默认由该路径列出的三位维护者把关改/server/则需控制面维护者介入。这种路径即所有权的机制把 GOVERNANCE.md 中抽象的组件级决策权落实到了可机器执行的 GitHub 规则上。Maintainer 的职责包括评审所负责区域的 PR帮助保持代码质量、兼容性与安全当变更影响其他接口面时要求跨组件评审在需要时保持 specs、实现、测试、文档与示例一致帮助贡献者成功落地变更。Project Maintainer仓库级最终决策者Project Maintainer 负责仓库整体方向并在常规组件评审无法解决问题时做出最终技术决策。在专门的MAINTAINERS.md出现之前CODEOWNERS 中兜底*规则下的 owner 被视为 Project Maintainer 的公开名单——对照上面的文件当前即为*规则列出的四人。Project Maintainer 的职责跨切面技术决策、治理文档更新、维护者准入与退出、仲裁评审僵局、确保重大变更遵循相应的设计流程。决策机制从日常变更到 OSEP日常变更六步 PR 流程绝大多数变更走 CONTRIBUTING.md 描述的标准 PR 流程视情况先在 issue 中讨论变更提交 PR通过自动化检查CI 检查由 .github/workflows/ 下的流水线承担如server-test.yml、execd-test.yml、sdk-tests.yml、verify-license.yml等获得受影响区域维护者的评审处理反馈批准后合并。普通变更由维护者评审加大致共识rough consensus决定。组件级决策仅影响单个子系统的变更由该子系统的维护者作为主要决策方其评审在实现细节、代码结构、测试和组件内运维行为上最具权重。若变更波及多个子系统合并前应让相关维护者参与。跨切面与安全敏感决策影响面更广的变更需要更宽的评审文档列举了典型范围specs/中的公共 API 或 schemaSDK 接口或生成物CLI 行为生命周期语义运行时隔离或安全保证ingress、egress 或认证行为发布流程或仓库级工具链。对这类变更维护者应当从所有实质受影响的面寻求显式评审而不仅是补丁首先触及的那个目录。这与 CODEOWNERS 的粒度形成互补路径规则保证有人负责治理文档则要求评审视野超出路径边界。重大设计变更与 OSEPOpenSandbox 对重大变更采用OSEPOpenSandbox Enhancement Proposal流程。以下变更预期需要 OSEP引入重大功能或架构变更修改核心 API 或运行时行为影响安全模型或隔离保证。OSEP 的公开流程记录在 oseps/README.md 与 oseps/CONTRIBUTING.md。当 OSEP 被要求时实现应遵循已批准的设计方向而不能仅靠代码评审绕开它。仓库中 OSEP 机制是真实运转的oseps/README.md 列出了从 OSEP-0001FQDN 出站控制到 OSEP-0023Credential-Bound TLS 拦截的 23 个提案每条都带状态与更新日期。从 oseps/CONTRIBUTING.md 可以看到提案的生命周期定义状态含义draft起草中尚未进入正式评审provisional维护者认可方向设计细节未定implementable设计已批准并通过合规检查可进入实现implementing代码正在合入SDK 同步进行中implemented功能达到 GA 且文档完整withdrawn/rejected提案撤回 / 被否决发起新提案有标准化工具运行oseps/init-osep.sh Proposal Title会基于 osep-template.md.template 复制模板、填充元数据并生成顺序编号的草稿文件也支持--status、--author等选项模板结构参考了 Tekton 的 TEP。共识与投票OpenSandbox 对多数技术决策偏好lazy consensus惰性共识受影响维护者同意即可推进若有人提出异议应在 PR、issue 或 OSEP 讨论中解决。若合理时间内无法达成共识Project Maintainer 可对参与投票的 Project Maintainer 进行简单多数表决每位参与投票的 Project Maintainer 一票存在直接利益冲突时应回避平票则提案不通过维持现状。这些一般性投票规则适用于技术争议与设计决策维护者提名与晋升则遵循下文专门的选举人资格与批准阈值。评审与合并预期合并前的硬性预期相关 CI 检查通过或失败已被理解并获维护者接受至少一位受影响区域的维护者评审过该变更跨切面变更在可行时由所有实质受影响区域评审破坏性变更必须明确标注并附迁移指引行为变化时同步更新文档与测试。维护者可以在以下情况拒绝或推迟变更与已批准的设计方向冲突引入不必要的兼容性风险在缺乏强理由的情况下削弱安全或隔离在单个变更中混入不相关工作。公共接口与兼容性OpenSandbox 把四类接口面视为公共契约specs/中的 API 规范、已发布的 SDK、CLI 行为、已文档化的配置与部署行为。维护者应尽可能优先采用增量式、向后兼容的变更。修改公共契约时应在同一变更中在可行时更新或核对受影响的实现、SDK、文档、示例与发布物。仓库的 specs/AGENTS.md 进一步要求契约变更影响下游时必须阅读最近的消费者指引server、SDK、组件 README/DEVELOPMENT、cli README形成契约 → 消费者的影响面清单保证一次契约修改不遗漏任何公共接口面。发布治理发布通过仓库内的公开工作流与脚本管理包括 .github/workflows/ 下的 GitHub Actions 流水线与 docs/community/release-automation.md 中记录的发布工具链。从 workflows 目录可见其覆盖面各组件发布流水线publish-server.yml、publish-components.yml、publish-cli.yml、publish-helm-chart.yml、publish-*-sdks.yml等、发布前置检查release-preflight.yml、Helm 发布测试helm-release-test.yml以及真实环境 E2Ereal-e2e.yml等。负责某发布目标的维护者需保证目标有相应的验证发布说明准确反映用户可见变更版本号与 tag 遵循文档化的发布规范。沟通渠道公开协作渠道有四个各负其职GitHub Issuesbug、功能请求、实现问题GitHub Discussions更广泛的设计讨论与社区互助Pull requests具体的代码与文档评审OSEPs重大设计工作。安全问题走 SECURITY.md 的私密报告指引不在公开渠道讨论。成为维护者提名、投票与阈值OpenSandbox 对贡献者晋升采用显式流程该流程借鉴自 containerd 项目治理并映射到 OpenSandbox 的既有角色Contributor、Maintainer组件所有权、Project Maintainer仓库级治理。采纳该流程时CODEOWNERS 中已记录的所有 Maintainer 与 Project Maintainer 全部保留。期望与准入门槛维护者身份体现的是已被证明的信任、持续兑现的承诺和对项目长期健康的投入。没有固定的 PR 或 commit 数量要求贡献量本身不构成晋升保证。候选Maintainer组件范围或Project Maintainer仓库级范围应展示超过三个月的有意义、持续的项目参与跨项目或目标组件的多样化贡献代码、评审、issue 分诊、文档、测试、社区支持可靠的技术判断力尤其是向后兼容、安全、错误处理与测试质量方面协作式沟通与建设性评审。此外Project Maintainer候选还需展示持续的项目级维护与领导可靠的跨组件与项目级技术判断在多个子系统、发布健康与治理方面的积极治理行为。提名流程晋升通过一个更新 CODEOWNERS 的公开 PR发起担保Sponsorship任一现有 Maintainer 或 Project Maintainer 可通过对CODEOWNERS开提名 PR 来担保候选人组件维护者写入具体组件路径Project Maintainer 写入兜底*名单。有意参选者可在公开 issue 或讨论中请求担保。提名 PR 内容PR 描述必须写明候选人的 GitHub 用户名、目标角色与路径范围、展示其具备资格的贡献链接、有投票资格的 Project Maintainer 名单、以及所需批准数。候选人接受候选人须在 PR 中显式评论接受提名。接受仅代表承诺履行角色职责不计为一次批准票。讨论与投票规则提名在 PR 上公开评审并投票关键规则讨论投票期提名 PR 自开启起至少保持打开7 个完整自然日提前达到批准阈值也不能缩短该期限选举人资格投票选举人为提名 PR 开启时、base 分支上CODEOWNERS兜底*规则记录的全部现任 Project Maintainer每人一票候选人不能为自己的提名投票候选人接受亦不计为批准批准阈值Maintainer组件范围至少获得有资格 Project Maintainer 的1/3肯定批准PR approve 或显式 LGTM向上取整到整人Project Maintainer至少2/3肯定批准向上取整到整人投票规则批准必须是肯定性的存在直接利益冲突者应回避弃权、未响应或回避都不计为批准也不降低分母公开异议异议应在 7 天期间于 PR 内公开讨论除规定投票外不设一致同意要求或个人否决权。需要注意提名阈值与日常技术决策所用的参与维护者简单多数是两套独立规则。决议与上板7 个完整自然日到期后由一位 Project Maintainer 核验批准阈值已达成且候选人已显式接受提名随后合并该 PR 并协调必要的仓库权限若阈值未达成PR 不能合并、直接关闭且不晋升不存在仅凭时间或贡献数量自动晋升的机制CODEOWNERS 始终是维护者身份的公开记录——晋升的唯一落点就是这份文件。维护者不活跃与移除维护者可随时通知项目主动卸任。若某维护者长期不活跃例如连续数月无有意义的评审或维护活动Project Maintainer 可以更新其维护者状态。移除应尊重且务实目标是让所有权记录保持准确而非惩罚性手段。对于严重违反项目预期的行为包括滥用项目权限或违反行为准则也可移除维护者。治理文档自身的变更规则对 GOVERNANCE.md 本身的修改同样走公开 PR 流程且应获得 Project Maintainer 评审并给予维护者与贡献者合理的评论机会后方可合并。若维护者认为需要更广泛的评审实质性治理变更可以通过 OSEP 或专门的治理讨论提出——即治理文档的修改与重大技术设计使用同一套公开 宽评审的方法论形成自洽的闭环。小结OpenSandbox 的治理模型可以概括为三条主线角色上用 CODEOWNERS 的路径规则把组件所有权落实为可执行的默认维护者映射兜底*规则则天然构成 Project Maintainer 名单决策上日常变更走 PR lazy consensus组件级变更由路径维护者主导跨切面与安全敏感变更要求全影响面评审重大设计则必须经由带状态机draft → provisional → implementable → implementing → implemented的 OSEP 流程人员上维护者晋升依赖 7 天公开讨论期、1/3 或 2/3 向上取整的批准阈值和以 CODEOWNERS 为唯一公开记录的落板机制。对于向 OpenSandbox 提交代码的开发者而言实操上最关键的两点判断是改动是否落在单一组件目录内是则等路径 owner 评审即可以及是否触及specs/、SDK 接口、隔离/网络语义或发布工具链是则需按跨切面变更准备更宽的评审重大者先走 OSEP。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenSandbox 治理机制解析：CODEOWNERS 角色模型、OSEP 决策流程与维护者晋升规则
OpenSandbox 治理机制解析CODEOWNERS 角色模型、OSEP 决策流程与维护者晋升规则【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandboxOpenSandbox 是一个安全、快速且可扩展的 AI Agent 沙箱运行时由生命周期服务端、execd/ingress/egress 运行时组件、Kubernetes 控制器和多语言 SDK 等多个子系统组成。本文基于仓库根目录的 GOVERNANCE.md 展开并结合 .github/CODEOWNERS、oseps/ 与 .github/workflows/ 等仓库实体说明该项目如何定义 Contributor / Maintainer / Project Maintainer 三级角色、如何在日常变更、组件级变更与跨切面变更之间划分决策权、如何通过 OSEP 流程管理重大设计以及维护者晋升的提名、投票阈值与上板机制。读完本文你可以理解在 OpenSandbox 中提交 PR、参与评审或推动重大设计时应遵循的完整协作与决策路径。治理目标与适用边界GOVERNANCE.md 开篇即声明该文档描述 OpenSandbox 当前的治理方式与技术决策如何产生目的是如实反映项目现行的开源开发实践并随着项目增长向更正式的治理模型演进。治理体系围绕五个目标设计对贡献者和用户保持开放日常决策务实高效技术方向公开透明对公共 API、运行时和安全敏感变更保持安全审慎在多组件、多维护者之间保持可持续性。治理文档的适用范围覆盖 OpenSandbox 仓库及其主要公共接口面具体包括范围仓库位置说明公共 API 与规范specs/沙箱生命周期、诊断、execd、egress 等 API 契约生命周期服务端server/Python 实现的沙箱生命周期管理运行时组件components/execd、ingress、egress、nodeagent 等Kubernetes 控制器kubernetes/控制器、Helm charts、CRD 与部署资产SDKsdks/Python、Go、JavaScript、C#、Kotlin 等语言 SDKCLI、示例与文档cli/、examples/、docs/命令行工具、示例与项目文档项目价值观文档要求维护者与贡献者的行为始终符合五项原则公开开发设计讨论、issue 跟踪、代码评审尽可能在公开场合进行、兼容性意识公共 API、SDK、CLI 行为和已文档化的用户工作流不应随意变更、安全优先影响隔离、网络、凭据或执行安全的变更需要额外审视、组件所有权与跨项目问责子系统维护者拥有各自领域跨切面变更需要更广泛的评审、文档与实现一致公共契约、代码、SDK、示例与文档应保持同步。这些原则在仓库中有直接的落地形态。例如 specs/AGENTS.md 明确要求将specs/目录下的规范文件视为公共接口的 source of truth 并优先采用增量式变更且当契约变更影响下游时必须同步阅读 server/AGENTS.md、sdks/AGENTS.md 及components/下的组件文档这正是文档与实现一致原则的工程化体现。三级角色模型Contributor、Maintainer 与 Project MaintainerContributor任何参与项目的人都算贡献者包括开 issue 或讨论、提交 PR、评审代码、改进文档/测试/示例/工具链。贡献者需要遵循 CODE_OF_CONDUCT.md、CONTRIBUTING.md漏洞上报则走 SECURITY.md 的私密报告通道——从 SECURITY.md 的内容看漏洞应通过 GitHub Private Vulnerability Reporting 提交而非公开 issue。Maintainer以 CODEOWNERS 为公开记录Maintainer 是被授权在仓库一个或多个部分评审与引导变更的贡献者。文档明确指出当前子系统维护者身份的公开记录就是 .github/CODEOWNERS 文件某一路径的 code owner 即该领域的默认维护者。查看实际的 CODEOWNERS 可以看到该映射关系的具体内容规则自上而下求值、最后一条匹配生效# Default owners (fallback for files not matched by specific rules) * jwx0925 hittyt Pangjiping ninan-nn # Control plane (server) /server/ Pangjiping hittyt jwx0925 Generalwin ninan-nn # Runtime components /components/execd/ Pangjiping hittyt ninan-nn /components/ingress/ Pangjiping hittyt Generalwin Spground /components/egress/ Pangjiping hittyt jwx0925 # Kubernetes controller /kubernetes/ Spground Generalwin fengcone kevinlynx ninan-nn hittyt Pangjiping # SDKs /sdks/ ninan-nn jwx0925 hittyt Pangjiping # Specs and docs /specs/ jwx0925 hittyt ninan-nn # OpenSandbox Enhancement Proposals /oseps/ Spground Generalwin fengcone kevinlynx Pangjiping ninan-nn jwx0925 hittyt也就是说改components/execd/的 PR 默认由该路径列出的三位维护者把关改/server/则需控制面维护者介入。这种路径即所有权的机制把 GOVERNANCE.md 中抽象的组件级决策权落实到了可机器执行的 GitHub 规则上。Maintainer 的职责包括评审所负责区域的 PR帮助保持代码质量、兼容性与安全当变更影响其他接口面时要求跨组件评审在需要时保持 specs、实现、测试、文档与示例一致帮助贡献者成功落地变更。Project Maintainer仓库级最终决策者Project Maintainer 负责仓库整体方向并在常规组件评审无法解决问题时做出最终技术决策。在专门的MAINTAINERS.md出现之前CODEOWNERS 中兜底*规则下的 owner 被视为 Project Maintainer 的公开名单——对照上面的文件当前即为*规则列出的四人。Project Maintainer 的职责跨切面技术决策、治理文档更新、维护者准入与退出、仲裁评审僵局、确保重大变更遵循相应的设计流程。决策机制从日常变更到 OSEP日常变更六步 PR 流程绝大多数变更走 CONTRIBUTING.md 描述的标准 PR 流程视情况先在 issue 中讨论变更提交 PR通过自动化检查CI 检查由 .github/workflows/ 下的流水线承担如server-test.yml、execd-test.yml、sdk-tests.yml、verify-license.yml等获得受影响区域维护者的评审处理反馈批准后合并。普通变更由维护者评审加大致共识rough consensus决定。组件级决策仅影响单个子系统的变更由该子系统的维护者作为主要决策方其评审在实现细节、代码结构、测试和组件内运维行为上最具权重。若变更波及多个子系统合并前应让相关维护者参与。跨切面与安全敏感决策影响面更广的变更需要更宽的评审文档列举了典型范围specs/中的公共 API 或 schemaSDK 接口或生成物CLI 行为生命周期语义运行时隔离或安全保证ingress、egress 或认证行为发布流程或仓库级工具链。对这类变更维护者应当从所有实质受影响的面寻求显式评审而不仅是补丁首先触及的那个目录。这与 CODEOWNERS 的粒度形成互补路径规则保证有人负责治理文档则要求评审视野超出路径边界。重大设计变更与 OSEPOpenSandbox 对重大变更采用OSEPOpenSandbox Enhancement Proposal流程。以下变更预期需要 OSEP引入重大功能或架构变更修改核心 API 或运行时行为影响安全模型或隔离保证。OSEP 的公开流程记录在 oseps/README.md 与 oseps/CONTRIBUTING.md。当 OSEP 被要求时实现应遵循已批准的设计方向而不能仅靠代码评审绕开它。仓库中 OSEP 机制是真实运转的oseps/README.md 列出了从 OSEP-0001FQDN 出站控制到 OSEP-0023Credential-Bound TLS 拦截的 23 个提案每条都带状态与更新日期。从 oseps/CONTRIBUTING.md 可以看到提案的生命周期定义状态含义draft起草中尚未进入正式评审provisional维护者认可方向设计细节未定implementable设计已批准并通过合规检查可进入实现implementing代码正在合入SDK 同步进行中implemented功能达到 GA 且文档完整withdrawn/rejected提案撤回 / 被否决发起新提案有标准化工具运行oseps/init-osep.sh Proposal Title会基于 osep-template.md.template 复制模板、填充元数据并生成顺序编号的草稿文件也支持--status、--author等选项模板结构参考了 Tekton 的 TEP。共识与投票OpenSandbox 对多数技术决策偏好lazy consensus惰性共识受影响维护者同意即可推进若有人提出异议应在 PR、issue 或 OSEP 讨论中解决。若合理时间内无法达成共识Project Maintainer 可对参与投票的 Project Maintainer 进行简单多数表决每位参与投票的 Project Maintainer 一票存在直接利益冲突时应回避平票则提案不通过维持现状。这些一般性投票规则适用于技术争议与设计决策维护者提名与晋升则遵循下文专门的选举人资格与批准阈值。评审与合并预期合并前的硬性预期相关 CI 检查通过或失败已被理解并获维护者接受至少一位受影响区域的维护者评审过该变更跨切面变更在可行时由所有实质受影响区域评审破坏性变更必须明确标注并附迁移指引行为变化时同步更新文档与测试。维护者可以在以下情况拒绝或推迟变更与已批准的设计方向冲突引入不必要的兼容性风险在缺乏强理由的情况下削弱安全或隔离在单个变更中混入不相关工作。公共接口与兼容性OpenSandbox 把四类接口面视为公共契约specs/中的 API 规范、已发布的 SDK、CLI 行为、已文档化的配置与部署行为。维护者应尽可能优先采用增量式、向后兼容的变更。修改公共契约时应在同一变更中在可行时更新或核对受影响的实现、SDK、文档、示例与发布物。仓库的 specs/AGENTS.md 进一步要求契约变更影响下游时必须阅读最近的消费者指引server、SDK、组件 README/DEVELOPMENT、cli README形成契约 → 消费者的影响面清单保证一次契约修改不遗漏任何公共接口面。发布治理发布通过仓库内的公开工作流与脚本管理包括 .github/workflows/ 下的 GitHub Actions 流水线与 docs/community/release-automation.md 中记录的发布工具链。从 workflows 目录可见其覆盖面各组件发布流水线publish-server.yml、publish-components.yml、publish-cli.yml、publish-helm-chart.yml、publish-*-sdks.yml等、发布前置检查release-preflight.yml、Helm 发布测试helm-release-test.yml以及真实环境 E2Ereal-e2e.yml等。负责某发布目标的维护者需保证目标有相应的验证发布说明准确反映用户可见变更版本号与 tag 遵循文档化的发布规范。沟通渠道公开协作渠道有四个各负其职GitHub Issuesbug、功能请求、实现问题GitHub Discussions更广泛的设计讨论与社区互助Pull requests具体的代码与文档评审OSEPs重大设计工作。安全问题走 SECURITY.md 的私密报告指引不在公开渠道讨论。成为维护者提名、投票与阈值OpenSandbox 对贡献者晋升采用显式流程该流程借鉴自 containerd 项目治理并映射到 OpenSandbox 的既有角色Contributor、Maintainer组件所有权、Project Maintainer仓库级治理。采纳该流程时CODEOWNERS 中已记录的所有 Maintainer 与 Project Maintainer 全部保留。期望与准入门槛维护者身份体现的是已被证明的信任、持续兑现的承诺和对项目长期健康的投入。没有固定的 PR 或 commit 数量要求贡献量本身不构成晋升保证。候选Maintainer组件范围或Project Maintainer仓库级范围应展示超过三个月的有意义、持续的项目参与跨项目或目标组件的多样化贡献代码、评审、issue 分诊、文档、测试、社区支持可靠的技术判断力尤其是向后兼容、安全、错误处理与测试质量方面协作式沟通与建设性评审。此外Project Maintainer候选还需展示持续的项目级维护与领导可靠的跨组件与项目级技术判断在多个子系统、发布健康与治理方面的积极治理行为。提名流程晋升通过一个更新 CODEOWNERS 的公开 PR发起担保Sponsorship任一现有 Maintainer 或 Project Maintainer 可通过对CODEOWNERS开提名 PR 来担保候选人组件维护者写入具体组件路径Project Maintainer 写入兜底*名单。有意参选者可在公开 issue 或讨论中请求担保。提名 PR 内容PR 描述必须写明候选人的 GitHub 用户名、目标角色与路径范围、展示其具备资格的贡献链接、有投票资格的 Project Maintainer 名单、以及所需批准数。候选人接受候选人须在 PR 中显式评论接受提名。接受仅代表承诺履行角色职责不计为一次批准票。讨论与投票规则提名在 PR 上公开评审并投票关键规则讨论投票期提名 PR 自开启起至少保持打开7 个完整自然日提前达到批准阈值也不能缩短该期限选举人资格投票选举人为提名 PR 开启时、base 分支上CODEOWNERS兜底*规则记录的全部现任 Project Maintainer每人一票候选人不能为自己的提名投票候选人接受亦不计为批准批准阈值Maintainer组件范围至少获得有资格 Project Maintainer 的1/3肯定批准PR approve 或显式 LGTM向上取整到整人Project Maintainer至少2/3肯定批准向上取整到整人投票规则批准必须是肯定性的存在直接利益冲突者应回避弃权、未响应或回避都不计为批准也不降低分母公开异议异议应在 7 天期间于 PR 内公开讨论除规定投票外不设一致同意要求或个人否决权。需要注意提名阈值与日常技术决策所用的参与维护者简单多数是两套独立规则。决议与上板7 个完整自然日到期后由一位 Project Maintainer 核验批准阈值已达成且候选人已显式接受提名随后合并该 PR 并协调必要的仓库权限若阈值未达成PR 不能合并、直接关闭且不晋升不存在仅凭时间或贡献数量自动晋升的机制CODEOWNERS 始终是维护者身份的公开记录——晋升的唯一落点就是这份文件。维护者不活跃与移除维护者可随时通知项目主动卸任。若某维护者长期不活跃例如连续数月无有意义的评审或维护活动Project Maintainer 可以更新其维护者状态。移除应尊重且务实目标是让所有权记录保持准确而非惩罚性手段。对于严重违反项目预期的行为包括滥用项目权限或违反行为准则也可移除维护者。治理文档自身的变更规则对 GOVERNANCE.md 本身的修改同样走公开 PR 流程且应获得 Project Maintainer 评审并给予维护者与贡献者合理的评论机会后方可合并。若维护者认为需要更广泛的评审实质性治理变更可以通过 OSEP 或专门的治理讨论提出——即治理文档的修改与重大技术设计使用同一套公开 宽评审的方法论形成自洽的闭环。小结OpenSandbox 的治理模型可以概括为三条主线角色上用 CODEOWNERS 的路径规则把组件所有权落实为可执行的默认维护者映射兜底*规则则天然构成 Project Maintainer 名单决策上日常变更走 PR lazy consensus组件级变更由路径维护者主导跨切面与安全敏感变更要求全影响面评审重大设计则必须经由带状态机draft → provisional → implementable → implementing → implemented的 OSEP 流程人员上维护者晋升依赖 7 天公开讨论期、1/3 或 2/3 向上取整的批准阈值和以 CODEOWNERS 为唯一公开记录的落板机制。对于向 OpenSandbox 提交代码的开发者而言实操上最关键的两点判断是改动是否落在单一组件目录内是则等路径 owner 评审即可以及是否触及specs/、SDK 接口、隔离/网络语义或发布工具链是则需按跨切面变更准备更宽的评审重大者先走 OSEP。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
