时常逛 Github 的人如果晓得，每一工程项目左上角都有两个 Star 快捷键。尽管它的译者是“月亮”，但将其认知为高度关注或点赞也许更加最合适：点选即代表者你对那个工程项目的全力支持与钟爱，因而很多高质量开放源码工程项目经年累月留下来都能赢得为数众多 Star。
不过，“二十年累之，化为乌有”的意外事件，前段时间出现在了 HTTPie 工程项目头上：昨天，HTTPie 工程项目合作开发者 Jakub Roztočil 在其非官方网志正式发布了一则该文——“我们是怎样丧失 54k GitHub Star 的
”。
二十年独得 54k+ Star
HTTPie，是两个开放源码的配置文件 HTTP 软件包，提供更多配置文件X310e来出访 HTTP 服务项目。与其他同类型工程项目不同点是：为尽量使终端产品的 API 可视化实用，HTTPie 是Cubzac构筑的。
自 2012 年 2 月 25 日正式发布第两个申明版已经开始，HTTPie 项目组就将工程项目代销在 GitHub 上了。Jakub Roztočil 说明道：“当我意识到自己的 API 试验结论可能会引发合作开发者街道社区的广为浓厚兴趣时，GitHub 做为标识符代销网络平台，或许是个极好的优先选择。”
在我看来，Jakub Roztočil 的优先选择没有错：多年来，HTTPie 合作开发项目组对工程项目不断更新，招揽了为数众多合作开发者的采用与赞誉，HTTPie 也因而渐渐正式成为了 GitHub 上最受欢迎的 API 工具，还是 GitHub 上最受欢迎的 80 个公共存储库之一，Star 数高达 54k+
。
Jakub Roztočil 对这一成绩表示感恩：“那个不起眼的工具居然招揽了如此庞大的街道社区，真是令人难以置信，GitHub 在这之中发挥了重要作用。”
不过，就在 HTTPie 发展一切顺利、即将迎来在 GitHub 上代销十周年之际，Jakub Roztočil 的两个误操，令 HTTPie 这二十年积攒的所有 Star 都凭空消失了。
Jakub Roztočil 懊恼表示：“我不小心将 HTTPie 工程项目的存储库设为私有了。”
54k+ Star 瞬间消失
那天，Jakub Roztočil 先是将自己的 jakubroztocil/jakubroztocil 设置为私有，即在其个人资料中隐藏了两个空的 README。随后，他只是想以相同的操作在组织资料中也隐去两个空 README 文件，不料却正式成为了“意外事件”的已经开始。
不晓得是否有人注意到，在 GitHub 进行配置文件和存储库时，通过用户和通过组织的命名虽有不同，但非常相似：name/name（用户）与 name/.github.（组织）——这也就是 Jakub Roztočil 误认为自己在另两个零 Star 的空存储库中的原因：“我没有意识到命名存在不一致，所以我错误地优先选择了私有化 httpie/httpie 而不是 httpie/.github。”
（注：httpie/httpie 是拥有 54k+ Star 的工程项目存储库，而 Jakub Roztočil 本来想隐藏的是 httpie/.github。）
也许有人会问：那将工程项目再公开不就好了？极好，可问题是 GitHub 有两个“无情”的设定：一旦将存储库设为私有，将永久删除其所有 Watch 和 Star。
也就是说，HTTPie 用二十年积攒留下来的 54k+ Star 一瞬之间就没了。
聊胜于无的“确认框”
按常理来说，手机里删个照片都会“温馨提醒”一下，对于这种具有较大影响的操作，GitHub 如果也会提醒吧？
“确实有两个确认框”，Jakub Roztočil 表示：“GitHub 会提醒你一句‘你将永远丧失那个存储库的所有 Watch 和 Star’。”
可是，那个确认框的内容一成不变：不论是对于没有 Star、没有内容的存储库，还是面对具有二十年历史、54k+ Star 的存储库，那个确认框都几乎一模一样（只有最后一行的 httpie/httpie 和 httpie/.github 不同）——这对此前刚在其个人资料中顺利隐藏了两个空 README 文件的 Jakub Roztočil 来说，确认框的提醒作用聊胜于无。
一起来对比下面两张图，你能区分出哪两个是空存储库可以安心删除，哪两个会重置已拥有 54k+ Star 的存储库吗？
Jakub Roztočil 无奈表示：“提醒内容应更结合实际，如果确认框中说‘你将丧失 54k+ Star’，那我肯定会停留下来。”
“双标”的 GitHub
可惜，以上分析及感想均产生于在“意外事件”出现之后。
彼时尚未意识到自己错误的 Jakub Roztočil，在完成操作后看到组织页面的时候，陷入了无尽的茫然：为什么我想要隐藏的空 README 文件还在，最受欢迎的 HTTPie 存储库却不见了？
片刻之后，Jakub Roztočil 突然意识到出现了什么，火速回到存储库试图改正，可直到半小时后 GitHub 才允许：这半小时中，GitHub 忙着级联删除 HTTPie 这二十年来所有的 Watch 和 Star。
Jakub Roztočil 沮丧道：“我没有办法阻止那个过程，便已经开始发邮件给 GitHub 寻求全力支持，可最后也只能在 Star 数降为 0 后，再将存储库申明。”
事发之后，Jakub Roztočil 希望 GitHub 能利用备份帮助其恢复 HTTPie 54k+ Star 的街道社区，因为 GitHub 自己也曾出现过类似意外：GitHub 项目组有次不小心将 GitHub Desktop 应用存储库设为私有，随后没几个小时就恢复了包括 Star 在内的一切，当时 GitHub 前 CEO 还特地说明是通过数据库备份恢复的。
但 GitHub 拒绝了 Jakub Roztočil 的请求，理由是这会导致不良影响，甚至即便 Jakub Roztočil 表示愿意为此提供更多经济补偿，GitHub 也还是拒绝。
对此，Jakub Roztočil 总结：“GitHub 可以通过备份恢复私有再申明的存储库，但前提是这得是他们自己的工程项目，而不是街道社区工程项目。他们最多给你发条推文呼吁一下。”
“GitHub 难道不该提供更多更好的用户体验吗？”
茫然过，慌乱过，无助过，也愤怒过，但最终 Jakub Roztočil 还是平静地接受了，毕竟一切已尘埃落定，54k+ Star 回不来了。所幸很多合作开发者在知情后纷纷重新点选了 Star，目前 HTTPie 的 Star 数也已达 4.5k+。（GitHub 地址：https://github.com/httpie/httpie）
“尽管我们的优先选择有限，但至少有一些经验教训想与你们分享。”Jakub Roztočil 在最后如此说道。为避免其他人也出现类似“意外事件”，Jakub Roztočil 结合 HTTPie 自身官网设计，对合作开发者提出了两点建议：
优化 UI/UX 设计：当用户要破坏/删除某样东西并产生较大影响时，提醒框如果准确反映后果严重性。
采用软删除：人无完人，难免都会犯错。就算采用硬删除，也尽量延迟其过程。
最后，Jakub Roztočil 所讲述的这段经历，出人意料地在 Hacker News 上引发了很多合作开发者的共鸣。
@vaishnavsm：“我真的很喜欢这篇该文。尽管作者或许对他们丧失了他的街道社区并且 GitHub 没有恢复它感到难过（老实说，所有人在类似情况下都会难受的），但他们也在高度关注未来，并用他们的个人经历做为我们所有人都可以学习的寓言。做为设计师和合作开发人员，我们也将根据其建议改进我们的软件包。谢谢 HTTPie，你赢得了一颗新 Star！”
@ghoomketu：“那个确认框的对比图真的很可怕，我看了两遍才发现最后一行不同。希望 Github 高层管理人员能尽快注意到这一点并加以改进。”
也有很多人终于在此刻爆发了对 GitHub 的不满。
@sefrost：“GitHub 自己犯了完全相同的错误，却能通过数据库备份修复它，这确实不公平。”
@bsuvc：“当然，作者如果对此次失误负责，但GitHub 难道就不该提供更多更好的用户体验吗？难道不小心私有化然后申明的存储库真的有必要清空其 Star 吗？这难道是工程项目作者和点选 Star 的合作开发者们想要看到的吗？”
那么在你看来，GitHub 又有哪些方面需要改进呢？
参考链接：
https://httpie.io/blog/stardust
https://news.ycombinator.com/item?id=31033758#31034195
END
《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造
—点这里↓↓↓记得高度关注标星哦~—
一键三连 「分享」「点赞」「在看」
成就一亿技术人
