我让互联网每周投票决定合并哪些代码。第2周：他们投票决定每天合并。

Source: Dev.to

上周日，我合并了第一个社区 PR。这周日，社区投票决定每天都合并。

实验

OpenChaos 是一个仓库，任何人都可以提交 PR，社区通过 GitHub 表情投票，票数最高的 PR 将被合并。所有内容都可以被更改——包括规则。

数字

星期一：看不见的投票

GitHub 的 API 默认返回 30 条结果。我们有 40 多个未合并的 PR。

较早的 PR——包括 #13（Rust 重写）和 #47（IE6 模式）——未在排行榜上显示。人们无法对看不见的内容进行投票。

我立即合并了修复。

有人会说我违背了自己的规则。但隐藏 PR 的 bug 并不是混沌，它只是出错了。你无法对是否看到选票进行投票。投票亭必须先正常工作。

先例： 内容等到星期日。基础设施在出错时才发布。

星期二：Rust 战争

两个 PR。相同的梗。执行方式却大相径庭。

• PR #13: “Rewrite it in rust” 由 @wvanlit 提交，是第 1 周的亚军，获得 458 票赞。但有一个问题：它根本无法编译。到了周中，它开始通过 CI，将梗变成了现实。

  评论出现了分歧：

  • “少写 js ⇒ 少出 bug”
  • “会 Rust 的人少，阅读/编写 Rust 的门槛高，这会让贡献变得更困难，却没有实质收益。”
  • “出错越多 = 越混乱。”

  @bpottle 进行调查并提交了 PR #91: “Rewrite it in Rust (for real)”（13 次提交，使用 Axum 后端，真正的 async），获得了 18 票赞。

教训： 民主并不奖励努力，而是奖励梗。

星期三：静默政变

当大家都在关注 Rust 的戏剧时，PR #51: “Chaos each day” 正在上升——一个将合并频率从每周改为每日的简单改动。

到星期三，它已经通过了 Rust 重写。到星期四，它获得了 300 多票的领先。到星期天早上，它已经有 788 票。

@matthewmayer 称我为“仁慈的独裁者”，并询问我什么时间合适。我说 09:00 UTC ——这能让我起床。@BetonZM 将 PR 更新为 9:00。

社区对 什么 进行投票。维护者决定 何时。治理正在形成。

“让混乱降临。之后——每小时合并一次代码，保持氛围。”

Thursday: The Math

Source: (保持原样)

七天七次合并，而不是七周七次。到第九天，PR #63: “Add Automatic Merge” 已进入队列，添加了 GitHub Actions 触发器——无需人工。

星期日：第二次合并

2026年1月18日 — 09:00 UTC

PR #51: “Chaos each day” 已合并，获得 +788 票。

下一次合并将在明天 09:00 UTC 进行。接下来是 Rust 重写——前提是它能够解决合并冲突。否则，1999 将提前到来。

最终排名

接下来会怎样

到下个星期天，OpenChaos 可能会：

• 用 Rust 编写
• 风格像 1999 年
• 在没有我的情况下运行

我不知道它会变成什么样。这正是重点。

正在出现的趋势

1. 速度赢得投票。
   每日合并的 PR 并不聪明也不搞笑。它只承诺更快的混乱。这已经足够。

2. 队列即路线图。
   有了每日合并，你可以看到接下来一周的变更排队。悬念从 谁会赢 转向 谁能存活。

3. 治理从混乱中涌现。
   第一次社区合并加入了点踩。第二次更改了合并时间表。社区的第一本能不是破坏，而是构建控制混乱的系统。

他们不是在破坏游戏，而是在制定规则。

∞ 的第 2 周。
下次合并在明天。

— Max (@skridlevsky)
openchaos.dev · GitHub