新智元报道
编辑：袁榭 拉燕
【新智元导读】手滑点错按钮，会有什么后果呢？GitHub大佬亲自用自身经历现身说法。
手一滑，误关闭了文档、PPT、会议窗口、网页，这是当代人生活的必有场景了。
至于影响，小到订不到机票车票、大到丢饭辙丢老婆，都是有可能的。
这种失误在开源程序界的明星那里，会有什么影响呢？
下文就会告诉你一个典型的例子。
Github网红项目
HTTPie for Terminal距离第一次上传，已经过去10年了，这可是一件值得庆祝的事。
如果大家还对这个项目不是很熟悉，首先要知道这是一个开源的CLI HTTP用户端软件。HTTPie与众不同之处在于，它是从零开始搭建的，目的是为了让终端的API交互尽可能的方便用户操作。
2012年2月25号，在哥本哈根的一个雨夜，HTTPie第一个公开版本在GitHub上发布。
发布者Jakub Rozto il说，他一直是GitHub的粉丝，多年前他就是GitHub的会员了。按Jakub Rozto il自述，他就是个身着格子衫的标准程序员，lol。
在那个时代，GitHub曾经在他们的首页上，非常骄傲地宣布，他们在风险投资中筹得了0美元的巨款，并且在他们旧金山的办公室里有很多美味的啤酒。
当Jakub Rozto il意识到，他做的API测试可能会让大开发者社群里的成员感兴趣的时候，他就知道GitHub就是他的首选发布站了。
事实也确实如此。
Jakub Rozto il还记得，当HttPie第一次成为Hacker News上最热门的链接，还有GitHub社群不断壮大的场景。
很多年来，开发人员仍然在不断完善这个项目，这个项目也吸引了越来越多人的注意。慢慢这个项目成为了GitHub平台上最时髦的API工具。而彼时的HTTPie项目也成为了有5.4万关注并评分者的大社群，
简而言之，看到这个项目能收获这么多的关注，实在是一件美妙的事。GitHub作为平台功不可没。
开发HTTPie的人员和GitHub是互利互惠的关系。前者收获了后者提供的开源平台的服务，而平台也因为这个项目的热门而收获不少。
在过去十年，差不多有上百万人浏览过这个项目的主页。这也反哺了GitHub和Microsoft，使其作为一家公司更加关注开源和社群的搭建。
可以说，项目和平台互相成就。
缘，妙不可言。
因误操作，5.4万评星蒸发
然而，如果你是5.4万对此项目关注并评分者的其中之一的话，这几周你会发现，你不再是了。
到底发生了什么呢？
因为一系列倒霉的误操作，Jakub Rozto il不小心把项目权限设置成「私密」了。然后GitHub就这么把他们搭建了10年的项目删掉了。
这意味着什么呢？
如果你是一名下游的维护人员，或者是此前关注过HTTPie通知的人，现在你得把托管项目重新看一遍。
另外，Jakub Rozto il还发布了一份安全声明。
而对评分者是一样的道理。如果你是其中之一的话。如果你在过去十年里给HTTPie点过赞，那么现在HTTPie这个项目不会在你的喜欢列表里再次出现了。
那么开发者为什么要设置私密呢？
这其实得怪GitHub。简单来说，如果把项目设置成私密，那么就会自动永久删掉所有的关注者和评星。Jakub Rozto il其实知道这一点，那么他为什么还要这么做呢？
Jakub Rozto il表示，最直接的原因就是，他误以为自己打开了一个完全不同的项目。这个项目页面里没有任何内容，也没有评星。
其实Jakub Rozto il只是想隐藏HTTPie的组织文档README。这是一份他前一周创建的文档，但是还没有机会往里面添加任何内容。
而让开发者走上错路的原因则是另一件毫不相关的事：就像他把README文档隐藏了一样，他把他个人的jakubroztocil/jakubroztocil用户页面也给隐藏了。
在涉及到档案文件和托管项目的时候，GitHub的概念模型会把所有的用户和组织都视为相似的实体。所以说，当开发者只是想简简单单的隐藏文档的时候，他不多注意时就很容易点击错到「私密」按钮。
这才导致了一切。
Jakub Rozto il一时糊涂，没意识到，命名这个特殊的项目包含README的配置文档有不一致的情况，并且对用户和组织的名称是不同的，一个是name/name，一个是name/.github。
这就是为什么他是把httpie/httpie搞成了隐藏，而不是httpie/.github。
但点击时该有确认窗口啊？难道不是吗？！
的确，GitHub在这时候会弹出确认窗口。这个功能的设计本意确实是让Jakub Rozto il这种状况中的用户别做傻事、点击错误选项。它的文本内容会告诉你「将永久失去所有的项目评星和所有本托管项目的关注者」。
蛮吓人的哦。
问题在于，一个完全没有关注者和评星的项目，与一个更新了十余年、关注者与粉丝过5.5万的项目，Github的确认提示窗口都是一样的：「警告：这可能是一个有毁灭性潜质的决定。」
说成白话，提示窗口的警告语等同于「你将爆破一栋建筑，如果内有人居，住户都会死。」
不过这个提示窗口没有任何随用户变化的特定内容，让不专注的用户摆脱无心的下意识自动模式。这种用户很容易读混这些警示语，以为建筑里没有人。
一个价值5.4万个评星的问题：下图里两个警告窗口的对话，哪个在针对初学菜鸟自己决定删掉也没大损失的项目，哪个又是在针对一个逾时十年、关注者形成可观社群的项目？
提示窗的对话文本里应该有更多的随不同项目背景变动的内容，比如在Jakub Rozto il这个项目上弹出时就该有「你将干掉5.5万关注者！」的文本。那肯定会让Jakub Rozto il停下来细看的。
你只是把项目改成私密了，可以再改回来嘛
Jakub Rozto il一开始也是这么想的。
大家可以想见Jakub Rozto il点击回到「组织」页面时的困惑：不仅README文档是空白的，整个非常受欢迎的托管项目也无处可寻。
片刻之后，Jakub Rozto il意识到发生了什么事。所以Jakub Rozto il点击按钮回到托管项目的设置页，来重新将其重新设置为公开。但在整整半个小时的努力后，GitHub仍然不允许Jakub Rozto il做到这点。
如果你在疑惑为什么耗时是这么长，那是因为GitHub花了这么长的时间，来级联式全部删除了Jakub Rozto il项目十年来累计的关注者。而且项目开发者没有办法阻止这个过程。
Jakub Rozto il所能做的就是开始给GitHub技术支持部门写电邮、刷新页面、并等待关注数达到零，然后Jakub Rozto il才能再次将项目页面设为公开。
为何GitHub不自行恢复这个项目？！
GitHub显然有托管在其上的开源软件项目的备份，并且确实能消除意外将托管项目误改为私密权限所造成的损害。
GitHub团队自己就曾不小心将GitHub桌面应用程序的托管页面设为私有一次。他们在几个小时内为自己恢复了一切。
以下是 GitHub前CEO对情况的解释：早上有开发人员误操作了。权限改回来是无法直接回复项目评星的，所以开发者们用数据备份整个完全还原了项目，就这样。
然而，在Jakub Rozto il这次的事件中，GitHub拒绝这样做，理由是会产生不良副作用和额外的资源耗费。
Jakub Rozto il甚至表示愿为所耗费的任何资源对GitHub提供经济补偿。但遗憾的是，他们拒绝了。除了在平台上恢复最悠久和最受欢迎的软件项目及关注者社区之外，GitHub似乎还有其他优先偏好。
所以问题的答案很不幸地非常明显：GitHub会恢复权限误设为私密的开源软件项目，只要哪个项目是自己的就好。至于社区里其他人的项目嘛，自求多福吧，顶多给你个安慰性的推特回复。
吸取的教训
聪明人从不浪费任何一次挫折。开发者们现在的选择余地很小，但的确能学到好几条很值得分享的教训：
教训1：UI/UX设计原则
展示，而非告知。将确认选项的对话窗口设计为不需要用户多想的风格。
当用户要破坏/放弃某项目时，警示窗口不应将选项用抽象文本描述为潜在场景，这样需要让用户将文本叙述场景转化为直观的精神印象，然后才会权衡。
当主要选项的副作用是级联式删除时，更该如此。
开发者们现在把HTTPie桌面版的「删除」按钮设计成这样了
而且，不消说的是提示窗文本得反映潜在选项后果和副作用的严重性。当没有副作用时，对话框就不该有大块文本。否则的话，用户的注意力会很快被磨钝、不会放在应有的选项上。
教训2：数据库设计原则
尽量导入软删除选项。人都会犯错的，所以应该尽可能迟滞硬删除过程，给用户挽回空间。
教训3：与GitHub的关系
这次事故的确是开发者一方的人为无意失误，而且GitHub也明确表态他们无法定义务要帮助开发者们恢复项目。
所以，逾时十年的互惠互利关系最终被GitHub的服务条款与律师给定性了。开源软件人以为自己跟GitHub有更深厚情谊的话，纯属天真。
毕竟，GitHub有违开源精神的行迹已经不新鲜了，除非有公众意见的怒潮，他们一般不会改变决策。
而且他们的母公司微软，即使现在表面欢迎开源了，也并不是个真正名声上好的企业。
终局
尽管Jakub Rozto il的GitHub页面与评星化灰了，HTTPie项目仍然在蓬勃发展。
一开始只是个业余小项目的HTTPie，现在成为了专业公司，而且开发者们的团队在不断将HTTPie拓展成一个令用户满意预约的API开发平台。
HTTPie的网页版与桌面版的beta版，用户反馈良好，在接下来的数周内将会面向大众发售。
参考资料：
https://httpie.io/blog/stardust
营业执照公示信息