本文章来源背景

某一天（对就是前几天），我在图书馆搜索关于FastAPI的相关书籍时，找到了《Python FastAPI构建数据科学应用》这本书。该书在2022年5月出的第一版，也是第一次印刷，虽然它已经入住图书馆两年，但好像我是这本书的第一位读者。。。

开始读的时候我才发现，上一句话是有原因的。该书从Python基础讲起，后介绍了FastAPI作为后端框架比较基础的使用模型，在后面几章还有关于NumPy、scikit-learn、OpenCV等与主题不相干的知识（没错、和FastAPI都没有一点关系），但是我找到了一个很有趣的工具——HTTPie。

针对以前做后端接口调试和爬虫请求验证时，我一般使用Postman，但是相对HTTPie来说有些过于繁琐。即使可视化工具很好而且易于使用，但有时也会缺乏一些灵活性，不如命令行工具那么高效。另一方面，cURL是一个非常强大的工具，有数千个选项，但是对于测试简单的REST API而言，可能它会显得非常复杂和冗长。

在搜索相关资料时，我发现HTTPie还有一件“乌龙”事件：54k⭐在某一夜清零了，作者表示非常懊恼，官方专门写了一篇博客来反思整件事情。本着学习的态度，我决定将原文翻译成中文，并附上一些语言的翻译链接，基于作者不高的翻译水平与空空如也的翻译经验，本篇文章翻译质量可能不及您的预期，如果你想要更为精准、更为流利的翻译请移步👇。

我们是如何损失5.4万star的

社区翻译：Japanese, Russian

获得5.4万GitHub stars

HTTPie for Terminal 自第一次提交以来已经有 10 年了。

如果你对这个项目不熟悉，它是一个开源的 CLI HTTP 客户端。HTTPie 之所以与众不同，是因为我们从头开始构建，让终端的 API 交互尽可能地对人友好。

从首次公开发布开始，即 2012 年 2 月 25 日，在下雨的哥本哈根，我们就将项目托管在 GitHub 上。

我自几年前成为 GitHub 成员以来就一直是 GitHub 的粉丝（甚至穿着印有 Octocat 的 T 恤）。那时候 GitHub 的关于页面自豪地宣称他们没有接受过任何风险投资，并告诉你他们 SF 办公室有多少种美味的啤酒。

所以当我意识到自己解决 API 测试问题的成果可能会引起更广泛的开发者社区的兴趣时，GitHub 成为了一个显而易见的选择。而它确实引起了兴趣。

我记得 HTTPie 第一次成为 Hacker News 上最热门的链接时的激动，也看到了 GitHub 社区的增长。随着多年来我们不断改进项目，它不断吸引着广泛的采用。它成为了平台上最受欢迎的 API 工具，并且 GitHub 社区增长到了 54k 颗星和 1k+ 观察者。

这里有 2.89 亿个公共仓库，因此 HTTPie 跻身 GitHub 上最受欢迎的 80 个公共仓库之列； 在 99.99997203 百分位。 简而言之，看到这个不起眼的工具吸引了如此规模的社区，真是令人难以置信。 GitHub 在其中发挥了重要作用。

就像我们从 GitHub 的“社交编码”功能中受益一样，GitHub 也从我们在其平台上托管这个流行项目中受益。 过去的十年中，可能有数百万开发人员访问了我们的 GitHub 页面。 这有助于巩固 GitHub（微软）作为一家关心开源和社区的公司的地位。 这是一种共生关系。

失去 54k GitHub star

然而，如果您是我们 55k 的观星者和观察者之一，那么从几周前起您就不再是 💔

发生了什么？

由于一系列不幸的事件，我不小心将该项目的仓库库暂时设为私有。 GitHub 级联删除了我们花了 10 年建立的社区。

这意味着什么？

例如，如果您是下游维护者或之前关注 httpie/cli 通知的任何人，您将需要重新关注该仓库。 顺便说一句，我们最近发布了一个安全版本。

对于星星来说也是如此。 如果您是过去十年中曾为该仓库加注星标的 54K 人之一，那么该仓库将不再属于您的加星标项目。

你为什么将仓库设为私有？

温和地说，将仓库设为私有会永久删除所有观察者和星星，这是 GitHub 的一个特点。 我甚至意识到了这一点，但是我仍然没有格外注意地将 httpie/cli 设为私有。 那么，为什么呢？

直接原因是我认为我在另一个仓库中； 一个没有内容且没有星星的。 我实际上想做的是隐藏 HTTPie 组织 的配置文件自述文件，该文件是我在一周前创建的，但没有机会填充。

让我走上错误道路的是一个完全不相关的操作：我刚刚通过将 jkbrzt/jkbrzt 设为私有，在我的个人资料上做了同样的事情（即隐藏了一个空的自述文件）。

当涉及到配置文件和仓库时，GitHub 的概念模型将用户和组织视为非常相似的实体。 在这种情况下，由于我只想在我们组织的个人资料上重复相同的良性操作，所以我的大脑切换到自动驾驶模式。

我目前没有意识到这个包含配置文件自述文件的特殊仓库的命名不一致，并且它对于用户和组织来说是不同的：name/name vs. name/.github.。

这就是为什么我继续将 httpie/cli 而不是 httpie/.github 设为私有，却没有意识到自己的错误。

但有一个确认提示，对吧？

这里确实有一个确认框。 它的目的是阻止像我这样的情况的用户做一些愚蠢的事情。 它告诉你*“你将永久失去这个仓库的所有星星和观察者。”* 这太可怕了。

问题在于，对于没有提交和星星的仓库以及具有十年历史和 55,000 名观星者和观察者的仓库，该框看起来完全相同。 上面写着*“警告：这是一种潜在的破坏性行为。”*

换句话说，盒子告诉你“你要拆除一座房子。 如果里面有人的话，他们都会死。”

但如果你混淆了地址并认为自己看到的是一栋空房子，它不包含任何具体的内容来让你摆脱自动驾驶模式。

一个 54k 星问题：这两个对话框中哪一个可以安全确认，哪一个会删除 10 年历史的社区？

对话应该更加符合上下文，并且再次解释一下，它应该说*“你将杀死 55,000 人。”* 这肯定会让我停下来。

所以您将其设置为私有，只需按下开关即可！

你可以想象当我回到组织页面时我的困惑，我不仅仍然可以看到空白如也的 README ，而且我们最受欢迎的仓库也找不到了。 过了一会儿我意识到发生了什么事。 所以我回到仓库的设置来切换开关。 但 GitHub 不允许我这样做——整整半个小时。

如果你想知道为什么这么久，那是因为 🥁 这就是 GitHub 花了多长时间级联删除我们十年来的观星者和观察者。 并且没有办法阻止这个过程。 我所能做的就是开始写信给 GitHub 支持，刷新页面并等待星星数量达到零，然后才能再次公开。

为什么GitHub不恢复？

GitHub 显然有备份。 而且确实可以弥补因意外将回购私有化而造成的损害。 GitHub 团队自己不小心将 GitHub Desktop 应用程序仓库 设为私有。 他们在几个小时内就为自己恢复了一切。 以下是 GitHub 前首席执行官对 当时情况的解释：

然而，在我们的案例中，他们拒绝这样做，理由是不良副作用和资源成本。 我们甚至为 GitHub 提供了所需资源的经济补偿。 但遗憾的是，他们拒绝了。 除了复兴其平台上最古老、最受欢迎的社区项目之一的社区之外，他们还有其他优先事项。

不幸的是，问题的答案如下：GitHub 将通过将其设为私有来恢复损坏的仓库。 但前提是这是他们自己的项目之一，而不是社区项目。 后者充其量只能得到一条推文。

得到的教训

人们不应该让一场好的危机白白浪费。 我们的选择是有限的，但至少有一些值得分享的经验教训。

第 1 课：UI/UX 设计

展示，而不是讲述。 以别让我思考的方式设计确认对话框。 当用户要破坏某些东西时，不要用抽象的词语将其描述为用户需要将其转换为心理图像并赋予其价值的潜在场景。 特别是当级联删除作为主要操作的副作用时。 例如，我们在 桌面版 HTTPie 中的处理方法如下：

当然，对话应该反映副作用的严重程度。 当完全没有副作用时，它应该是无需通知的。 否则，我们可能会浪费用户有限的注意力资本，从而降低用户的敏感度：

第 2 课：数据库设计

使用软删除。 人都是人，他们也会犯错误。 对于硬删除，请延迟该过程。

第 3 课：与 GitHub 的关系

这是我们这边的人为错误，GitHub 明确表示他们没有法律义务帮助我们。 我们长达十年的互利关系的基调是由 GitHub 的服务条款确定的。 认为还有更多的事情是天真的。

毕竟，GitHub 历来曾采取有 争议的行为 ，这些行为违背了开源和社区的精神，然后仅在公众愤怒的情况下才将其恢复。 而微软（现在拥有 GitHub）尽管最近对开源产生了浓厚的兴趣，但并不总是享有很高的声誉。

下一步是什么？

我们仍然希望 GitHub/微软能够改变他们机器般的态度，并有一天恢复该项目的社区。 他们仍然拥有做到这一点的所有数据和手段。 我们也希望他们改进 UI 和数据库设计，以防止将来 其他团队 发生这种情况。

与此同时，您可以通过分享这个故事并重新 star and watch 我们的仓库 来帮助我们。

至于我，我可能会暂时不再穿印有章鱼图案的 T 恤。

结语

尽管我们的 GitHub 星星已化为尘埃，但 HTTPie 的表现却从未如此出色。 最初只是一个业余项目，最近已经成为一家公司，我们的团队正在将 HTTPie 发展成为一个 API 开发平台（正如您对 HTTPie 的期望一样令人愉快）。HTTPie Web 和桌面版 的内测版已经收到了很好的反馈，我们迫不及待地想在接下来的几周内向公众发布它。

如果您想了解最新动态，可以加入我们的 Discord 社区或关注 @httpie。

✏️四个月后更新

对这个故事的兴趣让我们大吃一惊。 截至 22 日 8 月，该帖子已被超过 10 万人阅读，并在 Twitter 和其他地方被分享了数千次，并且连续几天成为 Hacker News 上的热门帖子。

我们还收到了来自开源社区的大量同情和公众支持的呼吁，我们对此深表感激。 结果，HTTPie for Terminal 在几个月内就重新获得了令人难以置信的 23,000 个观星者。

我们从未收到过 GitHub 的消息。 但至少在这篇文章发布后不久，他们就悄悄地改进了破坏性的“更改仓库可见性”对话框的 UI。

✏️更新二

自上次更新以来，一位负责收购 GitHub 的微软人士亲自在 Twitter 上联系了我。 他甚至声称找到了我们的星星！

然而遗憾的是，从那以后我们就没有收到他的消息了。 但我们为 T3 感到高兴，它删除的仓库GitHub 已成功恢复，包括所有分支和星星。

另一个证据证明完全恢复确实是可能的。

文章部分英文单词

（好吧我承认就是我不认识）