电脑之心报导
他们找 GitHub CEO 求救，但无计可施。
2022 年 2 月 15 日，GitHub 透过twitter网络平台该台了一篇最新消息：「他们的好友 HTTPie 前段时间不留神将他们设为的是淋浴间，失掉了大部份的 Star。假如你依然爱它，就给它两颗 Star 做为圣诞节礼品。」
10 年攒下的 Star 忽然应缴？这是咋？
二十年赢得 5.4W Star 的开放源码工程项目
HTTPie 工程项目的第二次递交却是在二十年以后。
可能将许多人对那个工程项目不如熟识，这是两个开放源码 CLI HTTP 应用程序。项目组Cubzac构筑了它，以使终端产品的 API 可视化尽量实用。
HTTPie（读音为 aitch-tee-tee-pie）可用作试验、增容和一般来说与 API 和 HTTP 伺服器可视化。http&https 指示容许建立和推送任一 HTTP 允诺。它采用单纯大自然的句法，并提供更多序列化和全彩输入。
从 2012 年 2 月 25 日在斯德哥尔摩的第二次申明递交后，工程项目译者 Jakub Roztočil 就始终在 GitHub 网络平台上代销该工程项目。他他们也是 GitHub 网络平台的死忠影迷。
这些年来，HTTPie 逐渐成长为网络平台上最受欢迎的 API 工具，收获了 5.4W 个 Star 和 1k 的关注。
HTTPie 工程项目受益于 GitHub 的「social coding」功能，同时，GitHub 也受益于自身网络平台上代销的那个受欢迎的工程项目。在过去二十年中，可能将有数百万开发人员访问了 HTTPie 工程项目的 GitHub 页面。
但在几周前，HTTPie 工程项目积累的 5.4W Star 一夜应缴。
在这篇博客中，工程项目译者 Jakub Roztočil 详细介绍了事情经过：
发生了什么？
我不留神将工程项目的 repo 设为的是私有，GitHub 级联删除了他们花费 10 年时间建立的社区。
这意味着什么？
假如你是一位下游维护者，或者曾经关注过
Star 也是一样，假如过去二十年里你曾为该工程项目加注 Star，那现在 HTTPie 应该已不再是你的 Star 工程项目列表中的一员。
为什么要将 repo 设为私有？
将 repo 设为私有会永久删除大部份关注者和 Star，这是 GitHub 的两个特性。我知道这一点，而且我显然无意 httpie/httpie 隐藏。
最直接的原因是我认为我在另两个 repo 中——两个没有内容且 0 Star 的工程项目。我真正打算做的是隐藏 HTTPie 组织的配置文件 README，这是我在一周前建立但没有机会填充的。
让我走上错误道路的是两个完全不相关的操作：我刚刚在我的个人资料上做了同样的事情（即隐藏了两个空的 README），将其设为
jakubroztocil/jakubroztocil 私有。在配置文件和存储库方面，GitHub 的概念模型会将用户和组织视为非常相似的实体。在这种情况下，由于我只是想在他们组织的个人资料上重复相同的操作，我的大脑切换到了「自动驾驶」模式。
目前我没有意识到那个包含配置文件 README 的特殊 repo 的命名存在不一致问题，并且它对于用户和组织有所不同：name/name 与 name/.github.
这就是为什么我一开始要隐藏 httpie/httpie，而不是 httpie/.github，并且没有意识到我的错误。
但是，还有两个确认流程？
确实有两个确认框，旨在阻止像我这样的情况下的用户做许多愚蠢的事情。它会告诉你「你将永远失去那个存储库的大部份 Star 和关注者」。
问题在于，对于没有递交和任何 Star 的 repo ，它的提示框和具有 10 年历史及 55k Star 与关注者的 repo 是完全一样的。它说的是：「警告：这是两个潜在的破坏性行动。」
套用一句话：两个盒子告诉你「你要拆房子！如果里面有人，他们都会死。」但假如你混淆了地址并认为你正准备拆的是两个空房子，那后果将不堪设想。
实际上，此处的对话应该更加结合上下文，并且再次解释一下情况，比如说「你即将杀死 55000 人。」那肯定会让我停下来。
一番操作后
当我回到组织页面时，你可以想象我的困惑，我不仅依然可以看到空的 README，同时他们最受欢迎的 repo 找不到了。片刻后，我意识到发生了什么事。所以我回到 repo 的设置来翻转开关。但 GitHub 不容许我这样做——整整半个小时。
为什么这么久呢？因为这是 GitHub 级联删除他们 10 年来的 Star 和关注者所花费的时间。而且我没有办法阻止那个过程。我所能做的就是开始发最新消息给 GitHub 寻求支持，刷新页面并等待 Star 数量达到零，然后才能再次将其申明。
为什么 GitHub 不给他们恢复呢？
GitHub 显然有备份，并且有恢复 repo 的方法。GitHub 项目组曾经他们不留神将 GitHub 桌面应用程序 repo 设为私有，然后他们在几个小时内就恢复了一切，当时前 GitHub CEO 给出的解释是：
然而，在他们的事件中，他们拒绝这样做，理由是操作具有不良影响，并且会消耗资源成本。他们甚至提出为所需的任何资源提供更多经济补偿，但遗憾的是，他们却是拒绝了。相对于在 GitHub 上恢复最受欢迎的社区工程项目之一以外，他们还有其他优先事项。
因此，GitHub 恢复存储库的前提是他们他们的工程项目，而不是社区工程项目。
经验教训
这次危机让他们得到了很多教训，这里主要分享 3 点：
教训 1：UI/UX 设计
弹出的对话框要清晰明了，减少抽象的文字说明。以一种不需要用户思索的方式设计确认对话框。当用户要删除或损坏某些文件时，不要用抽象的语言描述，以免让用户难以了解即将发生的状况，特别是会造成级联删除的行为。例如，以下是他们在 HTTPie for Desktop 中的处理方式：
对话框需要反映操作影响的严重性。当完全没有额外影响时，对话框应该尽量单纯，否则会浪费用户有限的注意力，从而降低用户的敏感度：
教训 2：数据库设计
采用软删除（soft-delete）。人非圣贤，孰能无过。人们在删除操作上可能将会犯错误，因此应该尽量采用软删除，延迟硬删除（hard-delete）操作。
教训 3：与 GitHub 的关系
这是他们的人为错误，GitHub 明确表示他们没有法律义务帮助他们。他们长达二十年的互惠互利关系是根据 GitHub 的服务条款确定的，除此之外，再无其他。
毕竟，GitHub 有过有争议的行为，这些行为违背了开放源码社区的精神。微软（已收购 GitHub）尽管拥有一定的开放源码精神，但并不总是有很好的声誉。
他们希望 GitHub / 微软 有朝一日能够改变他们的态度，并恢复他们的工程项目社区，他们拥有实现这一点的大部份数据和方法。他们也希望他们改进 UI 和数据库设计，以防止这种情况未来发生在其他项目组身上。
最后，尽管他们的 GitHub star 量化为虚无，但 HTTPie 现在发展得非常好，从最初做为两个副工程项目到现在变成了一家公司，他们的项目组正在将 HTTPie 发展成两个 API 开发网络平台。用作 Web 和桌面的 HTTPie 私有试验版收到了很好的反馈，他们迫不及待地想在接下来的几周内申明发布它。
参考链接：
https://httpie.io/blog/stardust
