社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  Git

5.4万颗星清零!GitHub上10年心血,开发者误操作项目消失

51CTO官微 • 3 年前 • 414 次点击  

点击蓝字 关注我们

了解与IT有关的人和事

来源:新智元

ID:AI_era


51CTO


手滑点错按钮,会有什么后果呢?GitHub大佬亲自用自身经历现身说法。



手一滑,误关闭了文档、PPT、会议窗口、网页,这是当代人生活的必有场景了。


至于影响,小到订不到机票车票、大到丢饭辙丢老婆,都是有可能的。


这种失误在开源程序界的明星那里,会有什么影响呢?


下文就会告诉你一个典型的例子。


01

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上有多达2.89亿的公开程序托管项目,HTTPie也成为了社群中排名前八十的公开项目,排名前99.99997203%.


简而言之,看到这个项目能收获这么多的关注,实在是一件美妙的事。GitHub作为平台功不可没。


开发HTTPie的人员和GitHub是互利互惠的关系。前者收获了后者提供的开源平台的服务,而平台也因为这个项目的热门而收获不少。


在过去十年,差不多有上百万人浏览过这个项目的主页。这也反哺了GitHub和Microsoft,使其作为一家公司更加关注开源和社群的搭建。


可以说,项目和平台互相成就。


缘,妙不可言。


02

因误操作,5.4万评星蒸发


然而,如果你是5.4万对此项目关注并评分者的其中之一的话,这几周你会发现,你不再是了。


到底发生了什么呢?


因为一系列倒霉的误操作,Jakub Roztočil不小心把项目权限设置成「私密」了。然后GitHub就这么把他们搭建了10年的项目删掉了。



这意味着什么呢?


如果你是一名下游的维护人员,或者是此前关注过HTTPie通知的人,现在你得把托管项目重新看一遍。


另外,Jakub Roztočil还发布了一份安全声明。


而对评分者是一样的道理。如果你是其中之一的话。如果你在过去十年里给HTTPie点过赞,那么现在HTTPie这个项目不会在你的喜欢列表里再次出现了。


03

那么开发者为什么要设置私密呢?


这其实得怪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。


04

但点击时该有确认窗口啊?难道不是吗?!


的确,GitHub在这时候会弹出确认窗口。这个功能的设计本意确实是让Jakub Roztočil这种状况中的用户别做傻事、点击错误选项。它的文本内容会告诉你「将永久失去所有的项目评星和所有本托管项目的关注者」。


蛮吓人的哦。


问题在于,一个完全没有关注者和评星的项目,与一个更新了十余年、关注者与粉丝过5.5万的项目,Github的确认提示窗口都是一样的:「警告:这可能是一个有毁灭性潜质的决定。」


说成白话,提示窗口的警告语等同于「你将爆破一栋建筑,如果内有人居,住户都会死。」


不过这个提示窗口没有任何随用户变化的特定内容,让不专注的用户摆脱无心的下意识自动模式。这种用户很容易读混这些警示语,以为建筑里没有人。


一个价值5.4万个评星的问题:下图里两个警告窗口的对话,哪个在针对初学菜鸟自己决定删掉也没大损失的项目,哪个又是在针对一个逾时十年、关注者形成可观社群的项目?



提示窗的对话文本里应该有更多的随不同项目背景变动的内容,比如在Jakub Roztočil这个项目上弹出时就该有「你将干掉5.5万关注者!」的文本。那肯定会让Jakub Roztočil停下来细看的。


05

你只是把项目改成私密了,可以再改回来嘛


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才能再次将项目页面设为公开。


06

为何GitHub不自行恢复这个项目?!


GitHub显然有托管在其上的开源软件项目的备份,并且确实能消除意外将托管项目误改为私密权限所造成的损害。


GitHub团队自己就曾不小心将GitHub桌面应用程序的托管页面设为私有一次。他们在几个小时内为自己恢复了一切。


以下是 GitHub前CEO对情况的解释:早上有开发人员误操作了。权限改回来是无法直接回复项目评星的,所以开发者们用数据备份整个完全还原了项目,就这样。



然而,在Jakub Roztočil这次的事件中,GitHub拒绝这样做,理由是会产生不良副作用和额外的资源耗费。


Jakub Roztočil甚至表示愿为所耗费的任何资源对GitHub提供经济补偿。但遗憾的是,他们拒绝了。除了在平台上恢复最悠久和最受欢迎的软件项目及关注者社区之外,GitHub似乎还有其他优先偏好。


所以问题的答案很不幸地非常明显:GitHub会恢复权限误设为私密的开源软件项目,只要哪个项目是自己的就好。至于社区里其他人的项目嘛,自求多福吧,顶多给你个安慰性的推特回复。


07

吸取的教训


聪明人从不浪费任何一次挫折。开发者们现在的选择余地很小,但的确能学到好几条很值得分享的教训:


教训1:UI/UX设计原则


展示,而非告知。将确认选项的对话窗口设计为不需要用户多想的风格。


当用户要破坏/放弃某项目时,警示窗口不应将选项用抽象文本描述为潜在场景,这样需要让用户将文本叙述场景转化为直观的精神印象,然后才会权衡。


当主要选项的副作用是级联式删除时,更该如此。


开发者们现在把HTTPie桌面版的「删除」按钮设计成这样了



而且,不消说的是提示窗文本得反映潜在选项后果和副作用的严重性。当没有副作用时,对话框就不该有大块文本。否则的话,用户的注意力会很快被磨钝、不会放在应有的选项上。


教训2:数据库设计原则


尽量导入软删除选项。人都会犯错的,所以应该尽可能迟滞硬删除过程,给用户挽回空间。


教训3:与GitHub的关系


这次事故的确是开发者一方的人为无意失误,而且GitHub也明确表态他们无法定义务要帮助开发者们恢复项目。


所以,逾时十年的互惠互利关系最终被GitHub的服务条款与律师给定性了。开源软件人以为自己跟GitHub有更深厚情谊的话,纯属天真。


毕竟,GitHub有违开源精神的行迹已经不新鲜了,除非有公众意见的怒潮,他们一般不会改变决策。


而且他们的母公司微软,即使现在表面欢迎开源了,也并不是个真正名声上好的企业。


08

终局


尽管Jakub Roztočil的GitHub页面与评星化灰了,HTTPie项目仍然在蓬勃发展。


一开始只是个业余小项目的HTTPie,现在成为了专业公司,而且开发者们的团队在不断将HTTPie拓展成一个令用户满意预约的API开发平台。


HTTPie的网页版与桌面版的beta版,用户反馈良好,在接下来的数周内将会面向大众发售。



参考资料:

https://httpie.io/blog/stardust


扫描上方二维码

关注51CTO官微

帮助一亿数字化人才终身成长

点击“阅读原文”了解更多

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/133038
 
414 次点击