Triage Party: 多人协作的 GitHub 分类处理 🎉

注意：这不是 Google 官方支持的产品

Triage Party 是一个无状态的 Web 应用程序，使用 GitHub API 为大型开源项目优化问题和 PR 的分类处理。

Triage Party 专注于减少处理新进 GitHub 问题和 PR 的响应延迟，确保对话不会消失在网络中。它源于 Google Container DevEx 团队为流行的开源项目做贡献的经验，如 minikube、Skaffold 和 Kaniko。

Triage Party 通过 YAML 配置，专为项目自托管而设计，可以在树莓派、Google Cloud Run 或 Kubernetes 等任何平台上运行。

创新特性
Triage Party 的生产应用
要求
试用
使用技巧
多人模式
看板模式（新）
数据新鲜度
文档

创新特性

多人模式：最多支持 20 名玩家同时参与分类
对话方向跟踪和筛选
跨 GitHub 项目或仓库查询
重复问题检测
GitHub 上无法实现的筛选：
- 项目成员的跟进延迟（responded: +15d）
- 反应（reactions: >=5）
- 评论热度（comments-per-month: >0.9）
代码审查状态跟踪（v1.2.0+）
看板仪表盘（v1.2.0+）
轻松在浏览器标签页中打开一组问题
所有页面、规则和筛选器的 YAML 配置
支持 GitHub Enterprise（通过 --github-api-url 命令行标志）
低延迟（但能拉取实时数据）

Triage Party 的生产应用

以下是实际应用的优秀示例：

要求

GitHub API 令牌，具有 public_repo 权限（只读）

试用

将 GitHub 令牌存储在磁盘上的某个位置：

echo 你生成的令牌 > $HOME/.github-token

运行：

go run cmd/server/main.go \
  --github-token-file=$HOME/.github-token \
  --config config/examples/kubernetes.yaml \
  --repos kubernetes/sig-release

如果你没有安装 Go，可以使用 Docker 运行 Triage Party：

export GITHUB_TOKEN="$(cat $HOME/.github-token)"
docker build --tag=tp .
docker run \
  --rm \
  -e GITHUB_TOKEN \
  -v "$PWD/config/examples/kubernetes.yaml:/app/config/config.yaml" \
  -p 8080:8080 tp

你也可以使用 GitHub CLI 的个人访问令牌来运行应用程序：

export GITHUB_TOKEN=$(grep oauth_token ~/.config/gh/hosts.yml| cut -d ":" -f 2 | sed "s/ //g")
docker build --tag=tp .
docker run \
  --rm \
  -e GITHUB_TOKEN \
  -v "$PWD/config/examples/kubernetes.yaml:/app/config/config.yaml" \
  -p 8080:8080 \
  tp

当 Triage Party 从 GitHub 拉取内容时，你会看到日志输出。第一次使用新仓库时，需要一些时间（在这个例子中约 45 秒）来下载必要的数据，然后 minikube 才能渲染页面。你的新 Triage Party 站点现在可以在 http://localhost:8080/ 访问，但在下载所需内容之前，初始页面加载会被阻塞。首次运行后，页面将在约 5 毫秒内从内存中渲染。

使用技巧

Triage Party 可以配置为接受你能想象到的任何分类工作流程。以下是一些技巧：

带箭头的框截图

使用蓝色的"箭头框"图标在新标签页中打开问题/拉取请求
如果点击后没有反应，您的浏览器可能在阻止弹出窗口
允许Triage Party弹出窗口的通知可能隐藏在URL栏中
规则最好有明确的解决方案，以便从列表中移除
页面最好定义好流程，使得分类完成后页面为空
如果日常或每周分类中出现无法采取行动的问题，请退一步调整规则和/或定义适当的解决方案

多人模式

使用任何页面右上角标有"Solo"的下拉菜单启用多人模式。在多人模式下，问题数量会根据您配置的玩家数量进行分配。由于Triage Party是无状态的，玩家分配是通过问题或PR除以总玩家数的余数来确定的。以下是我们发现在分类聚会中效果很好的工作流程：

等待参与者到达
会议主持人选择适当的玩家数量，并分享生成的Triage Party URL
如果有人稍后到达，我们可能会留出一个位置，如果他们没有出现，稍后再重新分配
会议主持人为每个参与者分配一个玩家编号
玩家逐节移动，使用"在新标签页中打开项目"功能快速处理问题
当玩家没有必要的背景来解决某个项目时，他们展示自己的屏幕并与其他玩家讨论
当有玩家离开时，会议主持人"重新分配"，所有玩家在下拉菜单中选择更新后的玩家数量

注意：多人模式效果最佳的前提是每条规则的"解决方案"字段都有明确的行动来解决项目并将其从列表中移除。

看板模式（新功能）

看板模式

在v1.2.0版本中，页面现在可以以看板仪表板的形式显示。列基于发现问题的规则，行是基于指派人的泳道。要查看真实世界的例子：

设计有用的看板仪表板的最佳实践：

规则应该以代表进度的方式设计和排序："未开始" -> "已开始" -> "审核中" -> "已完成"
规则最好是互斥的（没有问题匹配多个规则）
如果集合默认应以看板形式显示，在其配置中指定display: kanban
对于速度测量和时间估算支持，创建一个名为__velocity__的规则，包含最近关闭的问题。参见示例配置。

数据新鲜度

年龄截图

使用默认的Dockerfile，Triage Party至少每8分钟刷新一次数据，可通过--max-refresh标志设置。Triage Party会为热门页面提供更高的刷新率，默认最快每30秒（可通过--min-refresh标志设置）。这个默认设置比较保守，允许Triage Party在不触及GitHub API限制的情况下处理包含10,000个开放问题的仓库。

可以随时通过在浏览器中强制刷新来请求实时数据，通常是在重新加载页面时按住Shift键。参见您的浏览器的强制刷新方法。

您可以通过将鼠标悬停在页面顶部中央的"唯一项目"文本上来查看页面数据的新鲜程度。