开源治理CLI认证鉴权【免费下载链接】vouchA community trust management system based on explicit vouches to participate.项目地址https://gitcode.com/gh_mirrors/vou/vouch点击查看免费下载vouch 是一个社区信任管理系统用户在参与项目的特定环节例如提 PR之前必须先被显式背书vouched也可以被**显式除名denounced**从而被彻底封禁。vouch 项目本身就是一个典型的吃自己狗粮案例——它的贡献流程完全由 vouch 系统强制执行。读完本篇你将理解vouched 才能提 PR、未 vouched 的 PR 自动关闭、denounce 可跨项目复用这套信任门禁的完整规则、在本仓库中的真实落地方式GitHub Actions VOUCHED.td 信任清单以及如何一步步获得背书、避免触发除名。贡献门禁的基本规则CONTRIBUTING.md 开篇就明确了本项目的贡献前提必须 vouched 才能开 PRYou must be **vouched** to open a pull request.未获背书的提交者开出的 PR 会被自动关闭Issue 不设门禁Bug 与功能请求可以直接提 issue不需要先获得背书AI 使用约束如果你使用了 AI 辅助除非你完全理解 AI 给出的方案否则不要直接提交解决方案——只描述你遇到的问题把解决工作留给维护者。为什么要把 PR 门禁做这么严格原文给出了动机这个系统存在的原因是开源一直建立在信任之上而 AI 让默认信任trust-by-default不再可行因为生成看似合理但实际质量很低的贡献已经变得太容易了。README.md 的 Why? 一节从项目设计层面进一步解释了这一背景历史上理解代码库、实现改动、提交审查的成本足够高天然过滤了大量低质量贡献而 AI 工具大幅拉低了提交门槛因此项目转向显式信任模型——可信的人为新人背书被背书的人才能参与贡献。vouch 系统本身不规定具体政策谁可以被背书、如何被背书、背书带来什么权限完全交给接入项目自定义而 vouch 仓库自己选择的最严格策略就是PR 硬门禁。自动关闭机制仓库中如何 dogfood 这套系统未 vouched 的 PR 自动关闭不是口头约定而是由仓库内的工作流实现的。.github/workflows/vouch-check-pr.yml 定义了两个触发点on: pull_request_target: types: [opened, reopened] issue_comment: types: [created]PR 被打开或重新打开时执行check-pr动作并开启auto-close: true在 PR 的评论里输入/recheck时会重新执行一次检查——这正是先提 issue 获得背书、再把已打开的 PR 救回来这一流程的关键钩子vouched 文件更新后贡献者无需重开 PR只需评论/recheck触发复检。该工作流调用 check-pr 动作其 action.yml 暴露的核心输入包括输入默认值说明pr-number必填要检查的 PR 编号auto-closefalse是否自动关闭未 vouched / 被 denounced 用户的 PRdry-runfalse只打印会发生什么不实际改动require-vouchtruefalse时只封禁被 denounced 的用户vouched-file.github/VOUCHED.td信任清单文件路径template-file自定义关闭时回复贡献者的模板动作的输出status取值为skippedbot、vouched、allowed或closed。从 vouch/github.nu 中gh-check-pr的实现可以看到判定顺序作者以[bot]结尾 →skipped直接放行作者是具有 write 权限的协作者 → 视为vouched放行作者在 VOUCHED 清单中 →vouched作者被 denounced → 发一条作者被 vouch 清单显式封禁的评论并关闭 PR其余情况未 vouched 且require-vouch为 true→ 渲染关闭模板、发评论、关闭 PR。未 vouched 用户收到的是内置模板 github-pr-unvouched 渲染出的留言其核心内容是Hi {author}, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically.注意该模板中的仓库链接指向的是项目的 CONTRIBUTING 文档——也就是说被自动关闭的贡献者被直接引导到本篇所讲的如何获得 vouch流程上形成闭环。一个值得注意的细节vouch 仓库只部署了check-pr检查而没有部署 check-issue 动作。这与 CONTRIBUTING.md 中issue 可以直接提完全一致——门禁只作用于 PR 这一环节问题讨论保持开放背书流程本身也依赖先提 issue来完成。如何获得 Vouched五步流程与背后的自动化工具CONTRIBUTING.md 给出的官方流程是提一个 issue描述你想改什么、为什么改保持简洁用自己的语气写不要让 AI 代笔维护者如果认可会 approve 该 issue 并为你 vouch获得认可后即可提交 PR。FAQ.md 补充了语气获得 vouch 不应该困难vouch 主要防止的是低投入的 drive-by 贡献像在任何正常的人类社交环境里一样做自我介绍你就能获得 vouch。滥用信任则会带来下一节的后果。本仓库中 vouch 是如何被执行的维护者 approve 并为你 vouch这一步由两条工作流自动完成.github/workflows/vouch-manage-by-issue.yml监听issue_comment调用 manage-by-issue 动作.github/workflows/vouch-manage-by-discussion.yml监听discussion_comment调用 manage-by-discussion 动作。两者都配置了concurrency: { group: vouch-manage, cancel-in-progress: false }用于串行化对 VOUCHED 文件的并发写入避免两个人同时被 vouch 时互相覆盖。manage-by-issue 动作的 action.yml 定义了一组可配置的输入关键的有vouch-keyword/denounce-keyword/unvouch-keyword触发关键词逗号分隔默认分别为vouch、denounce、unvouchroles允许执行管理操作的 GitHub 角色默认admin,maintain,write,triageallow-vouch/allow-denounce/allow-unvouch分别开关三种操作默认都开启pull-request/merge-immediately把对 VOUCHED 文件的改动以 PR 形式提交而非直接推送需要pull-requests: write权限vouched-managers-repo/vouched-managers-file/vouched-managers-ref支持从另一个仓库的 VOUCHED 文件读取谁有管理权实现跨仓库信任管理。当符合角色的协作者在 issue 下评论时动作按以下语法匹配见 manage-by-issue/README.mdvouch— 为 issue 作者背书vouch user— 为指定用户背书vouch reason/vouch user reason— 带理由背书denounce、denounce user、denounce reason、denounce user reason— 除名unvouch、unvouch user— 从清单中移除匹配成功后动作把用户名写入仓库的 VOUCHED 清单、提交并推送输出status为vouched、denounced、unvouched或unchanged。提交信息会自动带上触发评论的链接便于审计谁在哪个评论里给了背书。信任清单VOUCHED.td 文件vouch 的背书名单是一个扁平的.tdTrustdown文件默认查找路径为VOUCHED.td或.github/VOUCHED.td可用标准 POSIX 工具直接解析。本仓库实际使用的 .github/VOUCHED.td 是一个纯用户名列表按字母序而 VOUCHED.example.td 展示了完整语法# 每行一个 handle不带 按字母序排列 username platform:username # 可选平台前缀如 github:mitchellh -platform:denounced-user # 减号前缀表示除名 -platform:denounced-user 除名理由add-user、check-user、denounce-user、remove-user等核心逻辑在 vouch/lib.nu 中实现vouch/file.nu 提供from td/to td编解码open/save对.td文件透明工作且保留注释与空行。手动管理时也可以直接用 CLI# 查看用户状态退出码 0 vouched1 denounced2 unknown vouch check username # 预览默认或就地写入清单 vouch add someuser --write vouch denounce badactor --reason Submitted AI slop --write实现见 vouch/cli.nu 中的add、check、denounce命令。对 AI 辅助贡献的约束CONTRIBUTING.md 专门用一段话约束了 AI 的使用方式如果你使用 AI除非你理解这些方案否则不要提交解决方案。否则只提交你遇到的问题让维护者来处理。结合第 1 步issue 必须用自己的语气写、不要让 AI 代笔可以归纳出本仓库对贡献者输入质量的完整要求问题描述必须来自真实使用者的一手观察且背书申请必须体现真实的人。这不是技术限制而是信任模型的准入条件——整个系统存在的理由README Why? 一节就是 AI 让可信度无法从提交行为本身推断。Denouncement除名与可跨项目复用的封禁名单CONTRIBUTING.md 的最后一节定义了除名denouncement规则如果你反复表现出糟糕的行为不读说明、无礼或煽动性等你会被denounced。这会将你加入一个封禁名单封禁你与本项目的交互以及任何镜像了本项目封禁名单的其他项目。这个镜像能力是 vouch 设计的一个特色。VOUCHED.example.td 的头部注释解释了为什么项目自己维护一份除名清单、而不是或除了使用平台的 block 功能我们选择维护一份除名清单而非或补充于平台自带的 block 功能这样其他信任我们的项目可以直接吸入slurp in我们的除名名单复用我们对不良行为者的既有判断。文件层面除名就是清单里的一行减号条目例如示例中的-github:badguy -github:slopmaster3000 Submitted endless amounts of AI slopcheck-pr/check-issue等动作对 denounced 用户是无条件封禁的无论require-vouch是否开启并会用固定文案关闭其 issue/PR而 manage-by-issue 动作 支持通过denounce关键词直接执行除名配合vouched-managers-*输入还可以引用其他仓库的清单来决定谁有权除名。FAQ.md 还澄清了两个常见质疑被 vouched 的用户只是获得与项目交互的资格并不获得合并 PR、推代码或发版的权限这些仍由现有审查与系统控制把关默认只有 admin 和具有 write 权限的协作者能 vouch/denounce普通被背书用户不能为他人背书。小结给贡献者的行动清单只想要 vouch 提一个简短的、自己语气写的 issue说明想改什么、为什么等待维护者 approve 与 vouch已有 PR 被自动关闭在获得背书后到该 PR 下评论/recheck触发复检见 vouch-check-pr.yml只想反馈 Bug直接提 issue 即可无需任何前置资格使用 AI 时只报告问题、不提交未经验证的解决方案守住底线反复的违规行为会触发 denounce并进入可能被其他项目复用的封禁名单若要在其他仓库接入同样机制可参考 README.md 的动作清单与 COOKBOOK.md 中的真实场景指南如配合 branch protection 使用 GitHub App 令牌。赞分享开源治理CLI认证鉴权【免费下载链接】vouchA community trust management system based on explicit vouches to participate.项目地址https://gitcode.com/gh_mirrors/vou/vouch点击查看免费下载相关推荐T3 Code 贡献指南从 vouch 信任体系到可被接受的 PR 实战T3 Code 贡献指南从 vouch 信任体系到可被接受的 PR 实战 T3 Code 是一个开源的编码 Agent 控制面agent harnessAI Agent代码智能体后端前端移动开发桌面应用HyperDX 贡献指南解读Vouch 准入机制、多工作区开发环境与测试矩阵实战HyperDX 贡献指南解读Vouch 准入机制、多工作区开发环境与测试矩阵实战 导读 本文是 HyperDX 开源可观测性平台以 ClickHouse 示例工程区块链DeepSpeed 贡献实战指南代码格式化门禁、PyTest 测试与基于 diff 的 CI 测试选择机制DeepSpeed 贡献实战指南代码格式化门禁、PyTest 测试与基于 diff 的 CI 测试选择机制 导读 本文面向希望向 DeepSpeed 提交代码人工智能大模型深度学习分布式训练预训练强化学习模型优化上一篇Phi-3-mini-4k-instruct 在 PyPTO-Gym 中的 NPU 迁移与 PyPTO 融合算子适配实战下一篇rafx阴影技术详解实现逼真光照的高级技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
开源治理CLI认证鉴权【免费下载链接】vouchA community trust management system based on explicit vouches to participate.项目地址https://gitcode.com/gh_mirrors/vou/vouch点击查看免费下载vouch 是一个社区信任管理系统用户在参与项目的特定环节例如提 PR之前必须先被显式背书vouched也可以被**显式除名denounced**从而被彻底封禁。vouch 项目本身就是一个典型的吃自己狗粮案例——它的贡献流程完全由 vouch 系统强制执行。读完本篇你将理解vouched 才能提 PR、未 vouched 的 PR 自动关闭、denounce 可跨项目复用这套信任门禁的完整规则、在本仓库中的真实落地方式GitHub Actions VOUCHED.td 信任清单以及如何一步步获得背书、避免触发除名。贡献门禁的基本规则CONTRIBUTING.md 开篇就明确了本项目的贡献前提必须 vouched 才能开 PRYou must be **vouched** to open a pull request.未获背书的提交者开出的 PR 会被自动关闭Issue 不设门禁Bug 与功能请求可以直接提 issue不需要先获得背书AI 使用约束如果你使用了 AI 辅助除非你完全理解 AI 给出的方案否则不要直接提交解决方案——只描述你遇到的问题把解决工作留给维护者。为什么要把 PR 门禁做这么严格原文给出了动机这个系统存在的原因是开源一直建立在信任之上而 AI 让默认信任trust-by-default不再可行因为生成看似合理但实际质量很低的贡献已经变得太容易了。README.md 的 Why? 一节从项目设计层面进一步解释了这一背景历史上理解代码库、实现改动、提交审查的成本足够高天然过滤了大量低质量贡献而 AI 工具大幅拉低了提交门槛因此项目转向显式信任模型——可信的人为新人背书被背书的人才能参与贡献。vouch 系统本身不规定具体政策谁可以被背书、如何被背书、背书带来什么权限完全交给接入项目自定义而 vouch 仓库自己选择的最严格策略就是PR 硬门禁。自动关闭机制仓库中如何 dogfood 这套系统未 vouched 的 PR 自动关闭不是口头约定而是由仓库内的工作流实现的。.github/workflows/vouch-check-pr.yml 定义了两个触发点on: pull_request_target: types: [opened, reopened] issue_comment: types: [created]PR 被打开或重新打开时执行check-pr动作并开启auto-close: true在 PR 的评论里输入/recheck时会重新执行一次检查——这正是先提 issue 获得背书、再把已打开的 PR 救回来这一流程的关键钩子vouched 文件更新后贡献者无需重开 PR只需评论/recheck触发复检。该工作流调用 check-pr 动作其 action.yml 暴露的核心输入包括输入默认值说明pr-number必填要检查的 PR 编号auto-closefalse是否自动关闭未 vouched / 被 denounced 用户的 PRdry-runfalse只打印会发生什么不实际改动require-vouchtruefalse时只封禁被 denounced 的用户vouched-file.github/VOUCHED.td信任清单文件路径template-file自定义关闭时回复贡献者的模板动作的输出status取值为skippedbot、vouched、allowed或closed。从 vouch/github.nu 中gh-check-pr的实现可以看到判定顺序作者以[bot]结尾 →skipped直接放行作者是具有 write 权限的协作者 → 视为vouched放行作者在 VOUCHED 清单中 →vouched作者被 denounced → 发一条作者被 vouch 清单显式封禁的评论并关闭 PR其余情况未 vouched 且require-vouch为 true→ 渲染关闭模板、发评论、关闭 PR。未 vouched 用户收到的是内置模板 github-pr-unvouched 渲染出的留言其核心内容是Hi {author}, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically.注意该模板中的仓库链接指向的是项目的 CONTRIBUTING 文档——也就是说被自动关闭的贡献者被直接引导到本篇所讲的如何获得 vouch流程上形成闭环。一个值得注意的细节vouch 仓库只部署了check-pr检查而没有部署 check-issue 动作。这与 CONTRIBUTING.md 中issue 可以直接提完全一致——门禁只作用于 PR 这一环节问题讨论保持开放背书流程本身也依赖先提 issue来完成。如何获得 Vouched五步流程与背后的自动化工具CONTRIBUTING.md 给出的官方流程是提一个 issue描述你想改什么、为什么改保持简洁用自己的语气写不要让 AI 代笔维护者如果认可会 approve 该 issue 并为你 vouch获得认可后即可提交 PR。FAQ.md 补充了语气获得 vouch 不应该困难vouch 主要防止的是低投入的 drive-by 贡献像在任何正常的人类社交环境里一样做自我介绍你就能获得 vouch。滥用信任则会带来下一节的后果。本仓库中 vouch 是如何被执行的维护者 approve 并为你 vouch这一步由两条工作流自动完成.github/workflows/vouch-manage-by-issue.yml监听issue_comment调用 manage-by-issue 动作.github/workflows/vouch-manage-by-discussion.yml监听discussion_comment调用 manage-by-discussion 动作。两者都配置了concurrency: { group: vouch-manage, cancel-in-progress: false }用于串行化对 VOUCHED 文件的并发写入避免两个人同时被 vouch 时互相覆盖。manage-by-issue 动作的 action.yml 定义了一组可配置的输入关键的有vouch-keyword/denounce-keyword/unvouch-keyword触发关键词逗号分隔默认分别为vouch、denounce、unvouchroles允许执行管理操作的 GitHub 角色默认admin,maintain,write,triageallow-vouch/allow-denounce/allow-unvouch分别开关三种操作默认都开启pull-request/merge-immediately把对 VOUCHED 文件的改动以 PR 形式提交而非直接推送需要pull-requests: write权限vouched-managers-repo/vouched-managers-file/vouched-managers-ref支持从另一个仓库的 VOUCHED 文件读取谁有管理权实现跨仓库信任管理。当符合角色的协作者在 issue 下评论时动作按以下语法匹配见 manage-by-issue/README.mdvouch— 为 issue 作者背书vouch user— 为指定用户背书vouch reason/vouch user reason— 带理由背书denounce、denounce user、denounce reason、denounce user reason— 除名unvouch、unvouch user— 从清单中移除匹配成功后动作把用户名写入仓库的 VOUCHED 清单、提交并推送输出status为vouched、denounced、unvouched或unchanged。提交信息会自动带上触发评论的链接便于审计谁在哪个评论里给了背书。信任清单VOUCHED.td 文件vouch 的背书名单是一个扁平的.tdTrustdown文件默认查找路径为VOUCHED.td或.github/VOUCHED.td可用标准 POSIX 工具直接解析。本仓库实际使用的 .github/VOUCHED.td 是一个纯用户名列表按字母序而 VOUCHED.example.td 展示了完整语法# 每行一个 handle不带 按字母序排列 username platform:username # 可选平台前缀如 github:mitchellh -platform:denounced-user # 减号前缀表示除名 -platform:denounced-user 除名理由add-user、check-user、denounce-user、remove-user等核心逻辑在 vouch/lib.nu 中实现vouch/file.nu 提供from td/to td编解码open/save对.td文件透明工作且保留注释与空行。手动管理时也可以直接用 CLI# 查看用户状态退出码 0 vouched1 denounced2 unknown vouch check username # 预览默认或就地写入清单 vouch add someuser --write vouch denounce badactor --reason Submitted AI slop --write实现见 vouch/cli.nu 中的add、check、denounce命令。对 AI 辅助贡献的约束CONTRIBUTING.md 专门用一段话约束了 AI 的使用方式如果你使用 AI除非你理解这些方案否则不要提交解决方案。否则只提交你遇到的问题让维护者来处理。结合第 1 步issue 必须用自己的语气写、不要让 AI 代笔可以归纳出本仓库对贡献者输入质量的完整要求问题描述必须来自真实使用者的一手观察且背书申请必须体现真实的人。这不是技术限制而是信任模型的准入条件——整个系统存在的理由README Why? 一节就是 AI 让可信度无法从提交行为本身推断。Denouncement除名与可跨项目复用的封禁名单CONTRIBUTING.md 的最后一节定义了除名denouncement规则如果你反复表现出糟糕的行为不读说明、无礼或煽动性等你会被denounced。这会将你加入一个封禁名单封禁你与本项目的交互以及任何镜像了本项目封禁名单的其他项目。这个镜像能力是 vouch 设计的一个特色。VOUCHED.example.td 的头部注释解释了为什么项目自己维护一份除名清单、而不是或除了使用平台的 block 功能我们选择维护一份除名清单而非或补充于平台自带的 block 功能这样其他信任我们的项目可以直接吸入slurp in我们的除名名单复用我们对不良行为者的既有判断。文件层面除名就是清单里的一行减号条目例如示例中的-github:badguy -github:slopmaster3000 Submitted endless amounts of AI slopcheck-pr/check-issue等动作对 denounced 用户是无条件封禁的无论require-vouch是否开启并会用固定文案关闭其 issue/PR而 manage-by-issue 动作 支持通过denounce关键词直接执行除名配合vouched-managers-*输入还可以引用其他仓库的清单来决定谁有权除名。FAQ.md 还澄清了两个常见质疑被 vouched 的用户只是获得与项目交互的资格并不获得合并 PR、推代码或发版的权限这些仍由现有审查与系统控制把关默认只有 admin 和具有 write 权限的协作者能 vouch/denounce普通被背书用户不能为他人背书。小结给贡献者的行动清单只想要 vouch 提一个简短的、自己语气写的 issue说明想改什么、为什么等待维护者 approve 与 vouch已有 PR 被自动关闭在获得背书后到该 PR 下评论/recheck触发复检见 vouch-check-pr.yml只想反馈 Bug直接提 issue 即可无需任何前置资格使用 AI 时只报告问题、不提交未经验证的解决方案守住底线反复的违规行为会触发 denounce并进入可能被其他项目复用的封禁名单若要在其他仓库接入同样机制可参考 README.md 的动作清单与 COOKBOOK.md 中的真实场景指南如配合 branch protection 使用 GitHub App 令牌。赞分享开源治理CLI认证鉴权【免费下载链接】vouchA community trust management system based on explicit vouches to participate.项目地址https://gitcode.com/gh_mirrors/vou/vouch点击查看免费下载相关推荐T3 Code 贡献指南从 vouch 信任体系到可被接受的 PR 实战T3 Code 贡献指南从 vouch 信任体系到可被接受的 PR 实战 T3 Code 是一个开源的编码 Agent 控制面agent harnessAI Agent代码智能体后端前端移动开发桌面应用HyperDX 贡献指南解读Vouch 准入机制、多工作区开发环境与测试矩阵实战HyperDX 贡献指南解读Vouch 准入机制、多工作区开发环境与测试矩阵实战 导读 本文是 HyperDX 开源可观测性平台以 ClickHouse 示例工程区块链DeepSpeed 贡献实战指南代码格式化门禁、PyTest 测试与基于 diff 的 CI 测试选择机制DeepSpeed 贡献实战指南代码格式化门禁、PyTest 测试与基于 diff 的 CI 测试选择机制 导读 本文面向希望向 DeepSpeed 提交代码人工智能大模型深度学习分布式训练预训练强化学习模型优化上一篇Phi-3-mini-4k-instruct 在 PyPTO-Gym 中的 NPU 迁移与 PyPTO 融合算子适配实战下一篇rafx阴影技术详解实现逼真光照的高级技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
