Helix · 平台功能说明

GitHub 组织管理
是怎么运转的

写给 HR 的一份完整说明 —— 不需要任何技术背景

适用范围　公司在 GitHub 上的 5 个组织
与 HR 的关系　员工修改 GitHub 用户名的确认环节会到 HR 手上
文档日期　2026 年 8 月 31 日
一句话说清这份文档。公司的代码放在 GitHub 上,分成 5 个「组织」。 谁在组织里,就能看到里面的私有代码库。以前员工离职时,把他从组织里踢出去 这件事没有任何机制保证,靠的是有人记得。现在这件事由系统自动完成, 而且每天核对一次。这份文档说明它是怎么做的、员工能自己做什么、以及 HR 在 其中的位置。

01这件事解决的是什么问题

公司在 GitHub 上有 5 个组织。进了组织,就能看到组织内私有代码库的内容 —— 这是一项实实在在的访问权限,和门禁卡、内部系统账号是同一个性质。

以前是怎样的

员工想加入某个组织,在飞书上提交一张审批单。审批通过之后,流程末尾还挂着 四个需要人动手的节点:三个「办理」(按不同组织分给不同的人,由他们到 GitHub 上 手工点一次「邀请」),外加一个「接受邀请」(由申请人自己再点一次)。 这四个节点已经在 2026 年 8 月 31 日撤掉了 —— 现在审批一通过,系统直接把邀请发出去。

问题不在申请这一头,而在离职这一头。整个过程从头到尾都发生在 GitHub 和飞书上, 公司的 IT 平台完全不知道谁在哪个组织里。既然不知道,离职流程也就无从下手 —— 在这套东西上线之前,离职流程从来没有回收过任何一条 GitHub 组织成员资格。 一个已经离开公司的人,对 5 个组织里私有代码库的访问权,取决于有没有人记得去手工删掉。

关键区别 「有人记得」不是一个机制。它在人手充足、交接顺畅的时候有效,而恰恰在忙乱、 交接不清、离职人数多的时候失效 —— 也就是最需要它有效的时候。

现在是怎样的

上线之后量出来的几个数

1016
组织成员资格总条数
(5 个组织合计)
331
系统认不出是公司哪位员工
的账号(开源组织里有大量外部贡献者)
0
已离职却仍在组织里的人
(上线第一天是 1,已清理)

第三个数是这套东西存在的意义所在:上线第一天就查出了一位已离职员工仍在 tikv 组织里 —— 那一条已经在 2026 年 8 月 31 日清理掉了,所以现在是 0。这个数应该永远是 0; 它一旦不是 0,就说明某个环节的回收没有生效。

上面的数字为 2026 年 8 月 31 日实测值。第二个数不会自己变小 —— 处理它需要人看一眼, 详见第 10 节「待处理清单」。

02员工自己能做的三件事

员工不需要找 IT,也不需要找 HR。三件事都在 Helix 里自己完成。

员工要做的事 在哪里做 谁来确认 确认通过之后
登记 / 修改自己的
GitHub 用户名		 「我的设置 → 基本信息」, 或「我的申请 → 创建申请 → 通用类」
两个入口是同一张表单		 本人的 HR Ops
缺失时回退 HRBP		 系统依次更新 SuccessFactors、Helix、飞书三处的人员信息
申请加入某个
GitHub 组织		 「我的 GitHub 组织」页面 该组织的负责人
走飞书上原有的审批流程		 系统自动发出 GitHub 邀请,员工再到 GitHub 点一次「接受」
查看自己在哪些
组织里		 「我的 GitHub 组织」页面 —— 随时可看 ——

为什么「登记 GitHub 用户名」这一件事这么重要

GitHub 上的账号名和公司的员工档案之间没有任何天然联系。系统要想知道 「GitHub 上这个叫 hawkingrei 的账号是我们哪位同事」, 唯一的办法就是这位同事自己登记过。这一条登记支撑着三件事: 自动加入要靠它把人加进去、每日核对要靠它认出名单上的人是谁、 离职回收要靠它找到该摘掉的账号。没有登记,这三件事对这个人全都不成立。

现状 在职员工 417 人,其中 154 人没有登记 GitHub 用户名(约四成)。 这个字段过去只在入职时的表单里采集一次,之后没有任何修改入口 —— 员工换了 GitHub 账号也无处更新。上表的第一件事,补的就是这个缺口。

这里是 HR 会被触达的地方

员工提交 GitHub 用户名变更之后,需要有人确认这确实是他本人。 这个确认不交给 IT,而是交给最了解这位员工的人:

员工提交 新用户名 ① 本人的 HR Ops 首选,责任跟着人走 不是按角色群发 没有 ② 他的 HRBP 自动回退,不需要 任何人转交 都无 ③ HR / IT 兜底队列 生产上目前 4 人 属于这种情况 确认的地方:桌面端「我的待办 → GitHub ID」,或手机上飞书卡片直接点开 —— 两边都能直接做决定。 员工提交后如果想改主意,在提交入口那里可以自己撤回。 整条链自动分派,不需要任何人手工转交;三格都不落空,单子不会烂在那里。
为什么不做成「所有 HR 都能批」:一张单子如果谁都能批,就等于谁都不必批。 指定到具体的人,单子才有人认领。

03自动加入规则:哪些部门入职就进组

有些人天然就该在某个组织里 —— 比如某个研发部门的所有工程师。为这类情况可以 配一条规则:「这个部门的人,入职后自动加入这个组织」,不必逐个提申请。

一条规则里配什么

配好之后,在界面上可以先看一眼命中范围:这条规则现在会命中多少人、 其中多少人因为没登记 GitHub 用户名而暂时进不去。确认无误再打开开关。

部门是按「子树」匹配的 —— 这一点最容易理解错

规则里填一个部门,命中的是这个部门连同它下面所有的子部门。 但它不会顺带命中一个只是名字开头相同的兄弟部门。

规 则 里 填 的 部 门 Engineering 公司部门树 Engineering ✓ 命中 规则本身指的这个部门 Engineering / TiDB ✓ 命中 子部门,一并算在内 Engineering / Cloud ✓ 命中 同上 Engineering / Cloud / SRE ✓ 命中 再往下几层也一样 Engineering Support ✗ 不命中 名字开头相同,但它是另一个独立部门
判断依据是部门层级的完整一段,不是文字前缀。所以 Engineering 覆盖它的整棵子树,而 Engineering Support 虽然前 11 个字一样, 却是部门树上另一个平级的部门,不在这条规则的范围里。
配规则时的实用建议 如果你想同时覆盖 Engineering 和 Engineering Support,那就是两条规则,不是一条。 配完先看命中人数是否符合预期,再打开开关。

04命中规则 ≠ 就进组:中间有三道闸

一条规则命中了某位新同事,并不意味着他此刻就会被加进组织。后面还有三道闸, 顺序固定。每一道闸拦下的人,处置方式都不一样。

规则命中这位同事 闸 ① 这个组织的自动加入开关打开了吗 让「先配规则、先看命中范围、确认对了再开闸」成为可能 没开 → 不动作 这是配置状态,不是异常 闸 ② 这个人现在有资格拿新权限吗 待离职、已离职、档案已注销的人一律不给 没资格 → 不给 这道闸是刻意的,不是遗漏 闸 ③ 他登记过自己的 GitHub 用户名吗 最常见的拦截点 —— 在职员工只有约 63% 登记过 没有用户名,系统根本不知道该邀请 GitHub 上的哪个账号 不是跳过,是一件待办 · 通知本人去补登记 · 单独计数、留下记录 三道闸都过 → 系统发出 GitHub 邀请 员工在 GitHub 上点一次「接受」,就正式进组 补登记用户名之后不需要任何人回来重新处理:下一位新同事入职时的检查,或者每日核对,会自然把他带进去。
第三道闸的处置方式是这套设计里最要紧的一点。如果「没有用户名」只是被静默跳过, 那么将近四成的人会永远进不了组,而且没有任何地方会说起这件事。 所以它被做成一件明确的待办:提醒本人、单独计数、留下记录。
给 HR 的一个具体用处 界面上预览一条规则时,会同时给出两个数:命中多少人,以及 其中多少人还没登记 GitHub 用户名。第二个数才是这条规则真正的落地率。 这个数偏高,说明该催一批人去补登记,而不是规则配错了。

05从入职到进组:完整流程

通道 A · 按规则自动加入 通道 B · 员工自己申请 新同事的人员信息进入系统 HR 系统同步,或入职当天的重放 按部门 / 职级匹配自动加入规则 部门按子树匹配(见第 3 节) 过三道闸(见第 4 节) 卡在第三道的人:通知他去补登记用户名 员工在「我的 GitHub 组织」提交申请 用户名会预填,但要本人确认一遍 飞书审批:该组织的负责人审批 沿用原有审批流程,按所选组织找到对应负责人 审批通过 直接在飞书上提交的旧单子也走同一条执行路径 系统尝试发出 GitHub 邀请 —— 四种结局 ① 邀请已发出 员工去 GitHub 点接受 7 天内没点会过期 → 系统自动重发一次 ② 他本来就在里面 不重复邀请 台账补上这条记录 没有人需要做任何事 ③ 转人工办理 这个组织还没配好凭证 权限该给,只是这一步 要人去点 —— 不算失败 ④ 失败 用户名填错、权限不够、 网络问题。原因会记下来 失败不留下假的记录 第 ③ 种是这套东西能在凭证到位之前就先上线的原因:审批确实过了、权限确实该给,只是这一步暂时由人完成。 把它记成「失败」,会让上线第一周看起来像一连串故障 —— 而实际上没有任何东西出错。 第 ④ 种不会在台账上留记录:一封从未发出的邀请不是一条成员资格,记下来会让离职时去撤销一个不存在的权限。
关于「7 天过期」 GitHub 的组织邀请 7 天后失效,而 GitHub 不会通知任何人。 所以系统每 4 小时核对一次邀请状态:已经接受的更新成正式成员; 超过 7 天的判为过期并自动重发一次,同时通知本人(绝大多数过期不是拒绝,是没看到); 而明确点了拒绝的不再重发 —— 反复邀请一个拒绝过的人是骚扰,不是服务。

06离职怎么结束

这是整件事最初要修的那一半。GitHub 组织成员资格现在是离职流程里的一项标准回收资源, 和内部系统账号、VPN、云平台权限并列。

离职流程启动 系统列出这个人所有的组织成员资格 一个组织一条,因为每个组织可以有自己的离职策略 逐条判断:这一条该不该收回 刻意不收回 · 豁免的社区组织 　(负责人的明确决定) · 认不出是谁的记录 　(系统不知道那是他) 见第 10 节待处理清单 立即执行,不等 24 小时宽限期 宽限期是给交还硬件用的,不是让访问权多活一天 从 GitHub 组织移除,台账同步更新 还没接受的邀请也一并取消,免得他隔天点了接受又进来 如果这一步做不到 凭证没配好、 GitHub 拒绝…… 绝不标成已回收 这一条留在待处理, 带上真实原因, 下一轮继续重试 为什么「做不到就说做不到」这条这么重要 台账上「已回收」这三个字,是日后所有人回答「这个人还有没有访问权」时唯一的依据。一条假的回收记录, 比一条明确的「还没收回」危险得多 —— 后者会有人去处理,前者会让所有人以为已经处理完了。 离职办理页面上的「将要回收什么」预览,和实际执行的清单逐条一致,包括豁免在内。
已离职却还在组织里 = 一个应该永远是 0 的数 这个数出现在管理页最醒目的位置,而且逐条留下记录。它不为 0 只有两种可能, 两种都绕过了离职流程:有人在 GitHub 上手工把一位离职者重新加了回去; 或者这个人离职时,系统还认不出那个账号是他,后来才对上。 上线第一天这个数是 1(一位已离职员工仍在 TiKV 组织里),现在它是一件带处理按钮的待办。

07有哪些组织,各自什么策略

组织 性质 离职时是否回收 坐席余量 加入这个组织谁来批
pingcap 社区组织 回收 还剩 22 个 产研 - 内核研发负责人
tikv 社区组织 回收 无真实上限 产研 - 开发者社区管理
pingcap-inc 公司内部 回收 只剩 3 个 刘寅、冯帅
PingCAP-QE 公司内部 回收 无真实上限 产研 - 工程效率
tidbcloud 公司内部 回收 还剩 46 个 产研 - 云数据库负责人
坐席数据为 2026 年 8 月 31 日实测值,系统每天刷新一次。 「谁来批」取自飞书审批流程当前的实际配置(按申请人所选的组织自动找到对应的人), 不需要申请人自己去找。 「无真实上限」不是查不到,而是这两个组织当前的 GitHub 计划本身不设可用坐席上限 —— 系统在这种情况下明确显示「无上限」,而不是编一个数字出来当警报。
这件事已经定了 pingcap 和 tikv 是社区组织,里面的成员未必都是公司员工 —— 所以曾经有个问题:一位离职的同事,有没有可能仍然是这个开源项目正当的维护者、 因此应该保留?结论是不保留:这两个组织和其它组织一样,离职就回收。 上线时发现的那一位已离职却仍在 tikv 里的同事,已经在 2026 年 8 月 31 日清理掉了。

「回收」和「豁免」是两个概念,不能混着理解

「是社区组织」是一个事实;「离职后可以留下」是一项政策。 系统把这两件事分开存放,所以完全可以出现「是社区组织,但离职照样回收」的配置 —— 这正是当前 5 个组织的状态:五个都是「离职就回收」。 改政策是改一个配置项,不需要动任何代码 —— 所以将来如果某个组织真的需要豁免, 改一下就行,而且改完在界面上看得见。

08谁能做什么,HR 在哪一格

GitHub 组织管理 组织 / 规则 / 成员台账 能 看 也 能 改 全局管理员 GitHub 管理员 研发侧组织负责人 只 能 看 审计员　·　安全员　·　管理层 看得到全部数据,但界面上不会给他们出现按钮 H R 的 位 置 不管组织,管「这是谁」 确认员工提交的 GitHub 用户名变更 (HR Ops → HRBP → HR/IT 兜底队列) 只 看 自 己 全体员工 自己在哪些组织里 · 提申请 · 改用户名
HR 与这一页的关系是虚线:HR 不配置组织、不管成员名单,但没有 HR 那一步确认, 系统就不知道 GitHub 上的账号对应公司哪位员工 —— 而自动加入、每日核对、离职回收 三件事全都建立在这个对应关系上。
角色 看组织与
成员台账		 配组织与
自动加入规则		 手工移除 /
关联成员		 确认员工的
GitHub 用户名变更
全局管理员 · IT 是是是 兜底才接
GitHub 管理员 · 研发侧组织负责人 是是是 否
HR Ops / HRBP 否否否 是 —— 这是 HR 的那一格
审计员 / 安全员 是否否 否
管理层 是否否 否
普通员工 只看自己 否否否
只能看的角色,界面上不会渲染出操作按钮 —— 摆一个按下去必然被拒绝的按钮, 比不摆更糟。

09系统自己会做的日常事

这一节的结论只有一句:HR 不需要盯着这件事。系统按固定节奏自己核对, 真有需要人处理的事,它会主动找到该处理的人。

节奏 做什么 为什么必须自动做
每 4 小时 核对已发出的邀请 GitHub 的邀请 7 天过期,而 GitHub 不通知任何人。没有这一步, 界面上会一直写着「已邀请」,而那个人早就错过了
每天凌晨 把台账和 GitHub 上的真实名单双向核对一遍,并刷新坐席用量 有人绕过系统直接在 GitHub 上被加进组织 —— 这不算错,组织负责人本来就能这么做, 但一条系统不知道的成员资格,离职时就收不回来
每周一上午 把待处理清单推给 GitHub 管理员和全局管理员 一个数字放在页面上,离「有人看到」还差一步:得有人主动打开那一页。 所以它得自己开口
两个刻意的设计,都是为了让提醒还值得看 没有待办就什么都不发。一封每周固定到达、写着「一切正常」的邮件, 第三周就会被人归到某个文件夹里,而第四周真出事的那封也会一起被归进去。
「等人接受邀请」不算待办。那是正常等待,不是问题。把它列进清单会让清单长期非空, 而一个长期非空的清单等于没有清单。
这一节对 HR 的意思 上面三行没有一行需要 HR 参与。GitHub 组织这件事上,HR 唯一需要动手的地方 只有第 2 节里那一个:确认员工提交的 GitHub 用户名变更。 其余的核对、提醒、回收,都由系统按节奏自己完成。

10待处理清单里有什么

管理页上的第一个页签就是「待处理」,每周一的摘要推的也是同一份清单 —— 两处用的是同一个来源,不会出现「界面上有、邮件里没有」这种情况。

四类待办,按「不处理的后果」排序,不按数量排

是什么 谁该处理 界面上能直接做什么
已离职却还在组织里
最严重,排第一位		 GitHub 管理员 一键移除 —— 走的和离职自动回收完全相同的路径
坐席快用完了 组织负责人 / 账单负责人 直接跳到 GitHub 的账单页。加坐席只能在 GitHub 上做, 系统能做的是把人送到那一页
批了但邀请还没发
这个组织的凭证还没配好		 GitHub 管理员 / IT 跳到组织的成员页手工邀请,并显示已经等了几天
认不出是公司哪位员工
背景数字,不催办		 GitHub 管理员 关联到某位员工,或者确认这是外部人员

关于「认不出是谁」的那 331 条

这些组织里本来就有大量外部贡献者。抽样查看了 30 个这样的账号, 其中相当一部分在个人资料里写着别家公司、某个基金会或某所高校 —— 他们本来就不是公司员工,永远也「认」不出来。

所以除了「关联到某位员工」之外,还有第二条出路:确认这是外部人员。 确认之后这一条离开待办清单,但仍然留在台账里 —— 外部协作者确实持有访问权, 只是离职回收这件事对不在公司人事系统里的人本来就不适用。

系统会给出建议(参考公开个人资料里的姓名、邮箱、公司),但任何时候都不会自动认定, 一定要人点一下确认。原因很直接:把一条成员资格挂到错误的人头上, 后果是那个人离职时被撤掉的是别人的访问权。少认一个的代价是有人多点一下, 认错一个的代价是一次错误的权限回收 —— 两者不对等。

两件曾经悬着的事,现在都有结论了(2026 年 8 月 31 日):
① 飞书那条审批流程已经改完。末尾四个需要人动手的节点(三个「办理」+ 一个 「接受邀请」)已经撤掉,飞书上的旧发起入口也已关闭 —— 现在这个申请只能从公司 IT 平台 发起,审批一通过系统直接发邀请,不再卡在任何人身上。
② pingcap 和 tikv 不做豁免。这两个社区组织和其它组织一样,离职就回收。 上线时发现的那一位已离职却仍在 tikv 里的同事,也已经清理掉了。