十年积累，54000GitHubStars一天清零：开源秘密史上的巨大意外损失，失去所有Stars。如果你还爱它，送它一颗星星作为情人节礼物。”10年积累的星星突然清零？这是怎么回事？昨天，项目作者JakubRozto?il在博文中正式回应了这件事。十年前，第一次提交HTTPie项目，一个拥有5.4WStar的开源项目，已经是十年前的事了。对于不熟悉这个项目的小伙伴，这是一个开源的CLIHTTP客户端。团队从使终端API交互尽可能人性化。HTTPie（发音为aitch-tee-tee-pie）可用于测试、调试以及与API和HTTP服务器的一般交互。http&https命令允许创建和发送任意HTTP请求。它们使用简单自然的语法，并提供格式化和彩色输出。自2012年2月25日在哥本哈根首次公开提交以来，项目作者JakubRozto?il一直在GitHub平台上托管该项目。他本人是忠实粉丝GitHub平台的。多年来，HTTPie逐渐成长为平台上最受欢迎的API工具，获得了5.4WStars和1k关注。HTTPie项目受益于GitHub的“社交编码”功能，GitHub也受益于在自己的平台上托管这个热门项目。在过去十年中，可能有数百万开发人员访问过HTTPie项目的GitHub页面。但几周前，HTTPie项目累积的5.4WStar一夜之间清空。在此博客中，项目作者JakubRozto?il详细介绍了发生的事情：发生了什么？我不小心将我项目的存储库设为私有，GitHub级联删除了我们花了10年建立的社区。这意味着什么？如果你是下游维护者，或者已经关注HTTPie的通知，你可能想重新关注repo。Stars也是一样，如果你在过去十年内Star过这个项目，那么HTTPie现在应该已经不在你的Star项目列表中了。为什么要将回购设为私有？将存储库设为私有会永久删除所有关注者和星标，这是GitHub的一项功能。我知道这一点，而且我显然无意隐藏httpie/httpie。最直接的原因是我认为我在另一个回购中——一个没有内容和0星的项目。我真正打算做的是隐藏HTTPie组织的配置文件README，这是我一周前创建但没有机会填充的。让我走上错误道路的是一个完全不相关的操作：我只是在我的个人资料上做了同样的事情（即隐藏一个空的自述文件），将jakubroztocil/jakubroztocil设为私有。在涉及配置文件和存储库时，GitHub的概念模型将用户和组织视为非常相似的实体。在这种情况下，由于我只是想在我们组织的个人资料上重复相同的操作，所以我的大脑切换到“自动驾驶仪”。目前我不知道这个包含配置文件README的特定repo的命名存在不一致，并且对于用户和组织来说是不同的：name/name与name/.github。这就是为什么我想首先隐藏httpie/httpie，而不是httpie/.github并且没有意识到我的错误。但是，也有一个确认过程？确实有一个确认框，旨在阻止像我这样的用户做傻事。它会告诉你“你将永远失去这个存储库的所有星星和追随者”。问题在于，对于没有提交和没有星星的回购，工具提示与拥有55,000个星星和关注者的10年历史的回购完全相同。它说的是：“警告：这是一个潜在的破坏性行为。”换句话说：一个盒子告诉你“你正在拆毁房子！如果有人在里面，他们都会死。”但如果你把地址搞混了，以为你拆的是空房子，后果不堪设想。实际上，这里的对话应该更具体一些，再次说明情况，比如“你将要杀死55,000人”。那肯定会让我停下来。你可以想象当我在一些操作后返回组织页面时的困惑，不仅我仍然看到一个空的README，而且我们最受欢迎的repo无处可寻。过了一会儿，我意识到发生了什么事。所以我回到回购协议的设置来拨动开关。但是GitHub不会让我这样做-半个小时。为什么这么久？因为那是GitHub花了10年级联删除我们的Stars和Followers所用的时间。而且我没有办法停止这个过程。我所能做的就是开始向GitHub发送消息以寻求支持，刷新页面并等待星数达到零，然后再将其公开。为什么GitHub不为我们恢复它？GitHub显然有备份，并且有办法恢复repo。GitHub团队自己曾经不小心将GitHub桌面应用程序repo私有化，然后他们在几个小时内恢复了所有内容，当时前GitHubCEO给出的解释是：然而，在我们的案例中，他们拒绝这样做，on理由是该操作会产生不良影响并消耗资源成本。我们甚至提出为需要的任何资源提供经济补偿，但遗憾的是他们拒绝了。除了恢复GitHub上最受欢迎的社区项目之一，他们还有其他优先事项。所以GitHub的recoveryrepository前提是自己的项目，不是社区项目。经验教训这场危机给我们上了很多教训。这里主要分享3点：第1课：UI/UX设计中弹出的对话框要清晰明了，减少抽象的文字描述。以不需要用户思考的方式设计确认对话框。当用户要删除或损坏某些文件时，不要用抽象的语言来描述，以免使用户难以理解即将发生的情况，尤其是会造成级联删除的行为。例如，这是我们在桌面版HTTPie中的处理方式：对话框需要反映操作影响的严重性。在完全没有额外影响的情况下，对话应该尽可能简单，否则会浪费用户有限的注意力，从而降低用户的敏感度：第2课：数据库设计使用软删除（soft-delete）。人做错事是逃不掉的。人们在删除时可能会出错，因此应尽可能使用软删除，而硬删除应延迟。第3课：与GitHub的关系这是我们的人为错误，GitHub明确表示他们没有法律义务帮助我们。我们长达十年的互惠关系由GitHub的服务条款定义，仅此而已。毕竟，GitHub曾有过违背开源社区精神的争议行为。微软（收购了GitHub）尽管有一定的开源精神，但并不总是享有盛誉。我们希望GitHub/Microsoft有一天能改变他们的态度并恢复我们的项目社区，他们拥有实现这一目标的所有数据和手段。我们还希望他们改进UI和数据库设计，以防止将来其他团队发生这种情况。最后，尽管我们的GitHubstar没有量化任何东西，但HTTPie现在发展得非常好，从最初的一个副项目到现在的一家公司，我们的团队正在将HTTPie发展成为一个API开发平台。用于Web和桌面的HTTPie私人测试版收到了很好的反馈，我们迫不及待地想在接下来的几周内公开发布它。
