新智元報道
編輯：袁榭 拉燕
【新智元導讀】手滑點錯按鈕，會有什麼後果呢？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