機器之心報道
編輯：蛋醬、小舟
我們找 GitHub CEO 求助，但為時已晚。
2022 年 2 月 15 日，GitHub 通過推特平台廣播了一則消息：「我們的朋友 HTTPie 最近不小心将自己設為了私密，丢掉了所有的 Star。如果你仍然愛它，就給它一顆 Star 作為情人節禮物。」
10 年攢下的 Star 突然清零？這是怎麼回事？
昨天，項目作者 Jakub Rozto il 在部落格中正式回應了這一事件。
十年獲得 5.4W Star 的開源項目
HTTPie 項目的第一次送出還是在十年之前。
可能一些人對這個項目不夠熟悉，這是一個開源 CLI HTTP 用戶端。團隊從頭開始建構了它，以使終端的 API 互動盡可能人性化。
HTTPie（發音為 aitch-tee-tee-pie）可用于測試、調試以及通常與 API 和 HTTP 伺服器互動。http&https 指令允許建立和發送任意 HTTP 請求。它們使用簡單自然的文法，并提供格式化和彩色輸出。
從 2012 年 2 月 25 日在哥本哈根的第一次公開送出之後，項目作者 Jakub Rozto il 就一直在 GitHub 平台上托管該項目。他自己也是 GitHub 平台的忠實粉絲。
這些年來，HTTPie 逐漸成長為平台上最受歡迎的 API 工具，收獲了 5.4W 個 Star 和 1k 的關注。
HTTPie 項目受益于 GitHub 的「social coding」功能，同時，GitHub 也受益于自身平台上托管的這個受歡迎的項目。在過去十年中，可能有數百萬開發人員通路了 HTTPie 項目的 GitHub 頁面。
但在幾周前，HTTPie 項目積累的 5.4W Star 一夜清零。
在這篇部落格中，項目作者 Jakub Rozto il 詳細介紹了事情經過：
發生了什麼？
我不小心将項目的 repo 設為了私有，GitHub 級聯删除了我們花費 10 年時間建立的社群。
這意味着什麼？
如果你是一位下遊維護者，或者曾經關注過 HTTPie 以擷取通知，你可能需要重新關注一下 repo。
Star 也是一樣，如果過去十年裡你曾為該項目加注 Star，那現在 HTTPie 應該已不再是你的 Star 項目清單中的一員。
為什麼要将 repo 設為私有？
将 repo 設為私有會永久删除所有關注者和 Star，這是 GitHub 的一個特性。我知道這一點，而且我顯然無意 httpie/httpie 隐藏。
最直接的原因是我認為我在另一個 repo 中——一個沒有内容且 0 Star 的項目。我真正打算做的是隐藏 HTTPie 組織的配置檔案 README，這是我在一周前建立但沒有機會填充的。
讓我走上錯誤道路的是一個完全不相關的操作：我剛剛在我的個人資料上做了同樣的事情（即隐藏了一個空的 README），将其設為 jakubroztocil/jakubroztocil 私有。
在配置檔案和存儲庫方面，GitHub 的概念模型會将使用者群組織視為非常相似的實體。在這種情況下，由于我隻是想在我們組織的個人資料上重複相同的操作，我的大腦切換到了「自動駕駛」模式。
目前我沒有意識到這個包含配置檔案 README 的特殊 repo 的命名存在不一緻問題，并且它對于使用者群組織有所不同：name/name 與 name/.github.
這就是為什麼我一開始要隐藏 httpie/httpie，而不是 httpie/.github，并且沒有意識到我的錯誤。
但是，還有一個确認流程？
确實有一個确認框，旨在阻止像我這樣的情況下的使用者做一些愚蠢的事情。它會告訴你「你将永遠失去這個存儲庫的所有 Star 和關注者」。
問題在于，對于沒有送出和任何 Star 的 repo ，它的提示框和具有 10 年曆史及 55k Star 與關注者的 repo 是完全一樣的。它說的是：「警告：這是一個潛在的破壞性行動。」
套用一句話：一個盒子告訴你「你要拆房子！如果裡面有人，他們都會死。」但如果你混淆了位址并認為你正準備拆的是一個空房子，那後果将不堪設想。
實際上，此處的對話應該更加結合上下文，并且再次解釋一下情況，比如說「你即将殺死 55000 人。」那肯定會讓我停下來。
一番操作之後
當我回到組織頁面時，你可以想象我的困惑，我不僅仍然可以看到空的 README，同時我們最受歡迎的 repo 找不到了。片刻之後，我意識到發生了什麼事。是以我回到 repo 的設定來翻轉開關。但 GitHub 不允許我這樣做——整整半個小時。
為什麼這麼久呢？因為這是 GitHub 級聯删除我們 10 年來的 Star 和關注者所花費的時間。而且我沒有辦法阻止這個過程。我所能做的就是開始發消息給 GitHub 尋求支援，重新整理頁面并等待 Star 數量達到零，然後才能再次将其公開。
為什麼 GitHub 不給我們恢複呢？
GitHub 顯然有備份，并且有恢複 repo 的方法。GitHub 團隊曾經自己不小心将 GitHub 桌面應用程式 repo 設為私有，然後他們在幾個小時内就恢複了一切，當時前 GitHub CEO 給出的解釋是：
然而，在我們的事件中，他們拒絕這樣做，理由是操作具有不良影響，并且會消耗資源成本。我們甚至提出為所需的任何資源提供經濟補償，但遺憾的是，他們還是拒絕了。相對于在 GitHub 上恢複最受歡迎的社群項目之一以外，他們還有其他優先事項。
是以，GitHub 恢複存儲庫的前提是他們自己的項目，而不是社群項目。
經驗教訓
這次危機讓我們得到了很多教訓，這裡主要分享 3 點：
教訓 1：UI/UX 設計
彈出的對話框要清晰明了，減少抽象的文字說明。以一種不需要使用者思索的方式設計确認對話框。當使用者要删除或損壞某些檔案時，不要用抽象的語言描述，以免讓使用者難以了解即将發生的狀況，特别是會造成級聯删除的行為。例如，以下是我們在 HTTPie for Desktop 中的處理方式：
對話框需要反映操作影響的嚴重性。當完全沒有額外影響時，對話框應該盡量簡單，否則會浪費使用者有限的注意力，進而降低使用者的敏感度：
教訓 2：資料庫設計
使用軟删除（soft-delete）。人非聖賢，孰能無過。人們在删除操作上可能會犯錯誤，是以應該盡可能使用軟删除，延遲硬删除（hard-delete）操作。
教訓 3：與 GitHub 的關系
這是我們的人為錯誤，GitHub 明确表示他們沒有法律義務幫助我們。我們長達十年的互惠互利關系是根據 GitHub 的服務條款确定的，除此之外，再無其他。
畢竟，GitHub 有過有争議的行為，這些行為違背了開源社群的精神。微軟（已收購 GitHub）盡管擁有一定的開源精神，但并不總是有很好的聲譽。
我們希望 GitHub / 微軟 有朝一日能夠改變他們的态度，并恢複我們的項目社群，他們擁有實作這一點的所有資料和方法。我們也希望他們改進 UI 和資料庫設計，以防止這種情況未來發生在其他團隊身上。
最後，盡管我們的 GitHub star 量化為虛無，但 HTTPie 現在發展得非常好，從最初作為一個副項目到現在變成了一家公司，我們的團隊正在将 HTTPie 發展成一個 API 開發平台。用于 Web 和桌面的 HTTPie 私有測試版收到了很好的回報，我們迫不及待地想在接下來的幾周内公開釋出它。
參考連結：
https://httpie.io/blog/stardust
IJCAI 2022 - Neural MMO 海量 AI 團隊生存挑戰賽
4月14日，由超參數科技發起，聯合學界MIT、清華大學深圳國際研究所學生院以及知名資料科學挑戰平台 AIcrowd 共同主辦的「IJCAI 2022-Neural MMO 海量 AI 團隊生存挑戰賽」正式啟動。
本屆賽事以「尋找未來開放大世界的最強 AI 團隊」為主題，通過在 Neural MMO 的大規模多智能體環境中探索、搜尋和戰鬥，獲得比其他參賽者更高的成就。比賽還設定新的規則，評估智能體面對新地圖和不同對手的政策魯棒性，在 AI 團隊中引入合作和角色分工，豐富了比賽内容，增強了趣味性。