今天要講的是一篇舊文，起因是昨天文章發出后補充的評論里提到了這么一句
開源社區開頭容易，人多了，思想碰撞了，“牧貓”的工作就難了。
這篇文章里對社區成熟度的衡量和發展有一定的討論。此外，Public Design 和 Open Discussion 相呼應，以后一定還會再講跟公開討論相關的主題。
以下原文，有所改動。
TiDB Internals[1]?論壇于四月底上線，目的是提供一個討論任何有關 TiDB 相關項目的設計與實現的平臺。在這篇文章里，我們將討論為什么開源社區應該有一個論壇，以及這個論壇如今發展得怎么樣了。
TiDB Internals 的 Internals 意思是內核或原理，借鑒自 Rust Internals 論壇，而不是內部或者秘密的意思。
我們可以通過社區成員，參與度，治理形式，以及影響力等維度來衡量社區的成熟度。這里介紹一個來自?ZoomQuiet[2]?的社區成熟度模型。
?L0?無社區。大家不知道應該到哪兒討論什么。?L1?有社區。大家知道到哪兒可以進行討論。?L2?社區有規約。大家知道到哪兒應該討論什么，否則有管理員出來糾正。?L3?社區可自治。大家知道社區目標以及管理規約，并明確成為組織者的條件和路徑。?L4?社區自成長。社區變成大家日常生活習慣之一，并自學發掘或制造各種機會，關聯各種資源，發展社區影響力。換句話說，社區歸屬感穩定。
大部分社區以 L4 形式啟動，因為創始成員往往是一小群充滿熱情和信念的人，TiDB 也是如此。
TiDB 的創始人都是充滿熱情和信念的開源軟件開發者，早期就加入社區的成員也是如此。
然而，隨著社區的成長，一小群人的規模下通過 over communication 來同步的信息和項目目標，逐漸無法及時傳遞給新成員。核心成員被非開發事務纏身，行為守則和最佳實踐成為部落知識，社區瞬間回到 L0 的狀態。
這就是今年四月底的時候 TiDB 社區的狀態。項目托管在 GitHub 上，但是整體表現是 open source code only 的。新成員不知道 TiDB 是如何開發的，因為 PR 突然地出現，蹦出來一群人 Review 和 Approve 以后，又匆匆地合并。一切都以新成員看不懂的形式在進行。社區當中沒有持久化地保存成員討論內容的渠道，因此新成員很難參與到社區中來。
實話說，GitHub issue 和 PR 從形式上是持久化地保存成員討論內容的渠道，TiDB 維護了自己的 Slack 頻道。然而，GitHub 上的評論很少被響應，Slack 只能保存近幾個月的聊天記錄。
我作為 TiDB 社區的一員，在看到這樣的情況的時候，首先就是期望把社區帶回 L1 的狀態，也就是大家知道到哪兒可以進行討論。所以我著手建立了 TiDB Internals 論壇。
L1 和 L0 的不同點在于大家知道到哪兒可以進行討論，前面我提到技術論壇解決了這個問題。不過實際上，論壇并不是唯一的解法。
在建立論壇之前，我在已經存在的郵件列表里發布了一個調查[3]，題為“你認為什么是適合 TiDB 社區的討論工具？”調查郵件把討論工具分成了主題討論和即時通信兩類。
隨后的討論表明，即時通信可以暫不考慮，一方面是它的信息濃度太小，另一方面是開發者各有所愛，Slack 或者微信能夠部分解決這個問題，但是都無法解決每一個人都知道到哪兒可以進行討論的問題。因此，問題就變成了選擇一個合適的公開進行主題討論的渠道。
關于即時通訊工具的問題，有一些新的想法。TiKV 社區的 Xuanwo 正在實驗一個橋接即時通信工具的方案[4]，或許能夠解決 Slack 不能保存所有信息的短處，以及各有所愛的問題。但是，信息濃度的問題是天然的，即時通信還是只能作為補充手段。
當時有這么幾種可能的選項擺在我面前。
1.從我參與 ASF 項目的經驗來看，郵件列表可以工作得很好。2.GitHub 的新功能 Discussion 看起來很酷，而且有好幾個新潮項目已經開始用了。3.Apache TVM 和 Rust 等著名的開源項目有自己的技術論壇。4.GitHub issue 或者其他 issue 追蹤工具也是不錯的候選。
首先排除掉的選項是 issue 追蹤工具。軟件開發離不開 issue 追蹤工具，但是它不適合開放式討論。
Issue 總是綁定在某個代碼倉庫上的，并且通常圍繞著一個確定且具體的主題。例如，報告一個缺陷或者記錄一個具體的開發項。然而，開放式的技術討論一開始往往非常模糊，不夠具體。例如，粗略的功能設想，或者單純展示一個小技巧。
Issue 的另一個不足是缺陷報告和各種開發項往往創建和更新頻率非常高，這使得開放式的技術討論經常被這些信息淹沒。在處理具體問題時，開發者往往有模式可尋甚至機械式地處理，而在進行開放式討論時更關鍵的是創造性的思維和聯想能力。
這不是說我們不用 issue 追蹤工具了，恰恰相反，TiDB 的開發絕不可能離開 issue 追蹤工具。然而，它不是我們回答到哪兒可以進行開放式的技術討論的答案。
回過頭來看，郵件列表 和 GitHub Discussion 和論壇，都是很好的候選渠道。它們在發布一個主題和在專門的線程里進行主題化的討論這一點上是一致的。只不過結果是論壇更適合 TiDB 社區的情況。
從我參與 ASF 項目的經驗來看，郵件列表可以工作得很好。The Apache Way[5]?強調了公開討論的重要性，并要求所有交流都發生在郵件列表上。
TiDB 在當時已經有郵件列表了，而且我們甚至就是在郵件列表上做的調查，為什么不能就用郵件列表作為討論的渠道呢？我把原因歸結到文化差異和時過境遷上。
關于第一點，大部分 TiDB 的開發者并不成長于郵件列表在開源社區中扮演重要角色的年代。對于 Linux 和早期的 ASF 項目來說，郵件列表是最流行和有效的選擇。相當多的 TiDB 開發者甚至不知道怎么訂閱郵件列表，使用郵件列表進行討論，等等。TiDB 的郵件列表在相當長的一段時間里并沒有吸引到足夠多的參與者，這也是我們無法把它簡單的作為討論工具的客觀原因。不像 ASF 項目被規定要使用郵件列表，TiDB 的開發者有權選擇自己的討論工具，很顯然，大部分人并不想用郵件列表。
關于第二點，不得不說人總是追逐新潮的東西。Rust 社區在 5 年前就停用了郵件列表，作為 ASF 項目的 Apache TVM 也將討論的主戰場遷移到了開發者論壇上，僅保留到郵件列表形式上的信息同步。必須承認，論壇對于下一代乃至當代的開發者來說，是一個更易于理解且更易用的討論工具。
GitHub Discussion[6]?是 GitHub 為開源項目社區專門打造的協同交流論壇。
基本上，它跟一個論壇沒什么兩樣。但是我們最終沒有選擇它，因為這個論壇必須綁定到一個代碼倉庫上。我當時說如果 TiDB 的項目組織形式跟?CockroachDB[7]?相似，是一個中央大倉庫的形式，那我們很有可能會采用 GitHub Discussion 作為無需運維的開箱即用方案。但很可惜，TiDB 社區不是這樣的情況，它是由一系列代碼倉庫組成的。GitHub Discussion 綁定到一個倉庫上無法適應 TiDB 社區的實際情況。
所以，我們選擇論壇實際上是通過排除法選出來的。在下一節里，我會講講論壇如今發展到什么程度了，你可以從中看出這是不是一個合適的選擇。
關于 GitHub Discussion 的問題，也有新的想法。源代碼親和確實是極大的一個優勢。論壇討論人數、議題和活躍度起來以后，社區有充足的議題和討論意愿，可以將對應的項目的 Discussion 功能打開，就地發布 Release 公告，討論技術設計等代碼問題。關于這一點，還需要持續調研和觀察 GitHub Discussion 的應用情況。
這篇文章最早寫成的時候，距離論壇建立大概過去了一個月，有超過 70 個注冊用戶和 10 篇熱烈討論的主題。在前一個公眾號發布的時候，已經有超過 160 個注冊用戶和近百篇主題發布。現在，論壇已經有超過 200 個注冊用戶，多篇有價值的技術討論發表在論壇上。
當然，傳統的運營指標并不是我們的目的，只是一個數字上的直觀感受。我們的目標是建立起社區，讓大家知道到哪兒可以進行討論。甚至更進一步的，社區有規約。大家知道到哪兒應該討論什么，否則有人出來糾正。
經過幾個月發展，論壇已經有比較好的目錄切分，幾乎每天都會有新的主題出現或者現有主題的回復。
當初籌備的?TiDB Dev Guide[8]?的提案，已經完成了前兩個章節，并且在某些貢獻者參與社區的過程中提供了可靠的內容支持。這里再次建議各位 TiDB 的貢獻者或者任何關注開源社區的人，閱讀一下 TiDB Dev Guide 目前已完成的?Contribute to TiDB[9]?一章。你一定會有收獲的。
論壇上提出的?Restructure Tests[10]?提案，已經在逐步實現，吸引了不少于三十位貢獻者參與。
論壇上提出的?Move parser back to pingcap/tidb[11]?提案，當前正在討論當中。
關于技術的討論和問答比比皆是。一部分關鍵的開發活動，例如 TiDB 和 TiKV 的開發計劃，以及社區決策，還有版本發布的信息也在論壇可以公開獲取和討論了。
如上所述，TiDB Internals 論壇已經吸引了相當數量的開發者的參與，并且從中誕生了若干個具體的開發項，例如 TiDB 測試框架的遷移，BR 和 Parser 并入 TiDB 倉庫等等。具體的開發項仍然會落實到 GitHub 上完成，但是早期的開放式討論會發生在論壇上。
TiDB Internals 論壇歡迎所有人討論關于 TiDB 相關項目的設計和實現，開源協同的工作方式，以及有意思的點子等等。不過需要注意的是，論壇不是一個支持團隊，關于 TiDB 使用一類的用戶問題解答，社區有專門的用戶論壇?AskTUG[12]?來支持。
這里列舉一些符合 TiDB Internals 論壇調性的主題，歡迎隨時發起或加入討論。
?重構一段代碼，例如查詢優化器的實現，但是不確定重構的影響和需要保持的兼容性范圍。?有一個初步的想法，需要聽一聽社區開發者們的意見，例如支持 TiDB 計算節點并行承擔單個查詢。?關于架構設計或代碼實現的疑問，想要請教模塊專家。?分享參與 TiDB 開發者社區的經驗或最佳實踐，亦或是對 TiDB 開發者社區的期待。
這段內容節選自?Producing Open Source Software[13]?一書，原文已經足夠好，因此只做搬運，講一講整個 Open Discussion 的大背景。
即使你已經將項目公開，你和你的創始人也會經常希望通過私下討論來解決困難的問題。這在項目的開始階段尤其明顯，因為此時需要做出許多重要的決定，而只有少量志愿者能夠勝任。你會發現公開討論的明顯缺點：郵件對話本身的延遲性，需要保留足夠的時間來達成一致，處理自以為是的幼稚的志愿者（每個項目都有；有些將來會成為明星貢獻者，而有些會永遠保持幼稚），也就是那些不能理解你為什么只希望解決問題X，而X明顯是大問題Y的子集的人。秘密決定并使之成為既成事實，或者至少成為聯合和有影響力的投票集團的堅實推薦，確實非常有吸引力。
不要這樣做。
盡管公開討論可能很笨重，但是從長遠來看這樣做更合適。私下里做出重要的決定就像是將貢獻者排斥出項目一樣。沒有重要的志愿者會愿意呆在這樣一個由秘密委員會做重要決定的環境里。此外，公開討論也會從其副作用中獲益，無論是多么短暫的技術問題，一經發起都會一直討論下去：
?討論有助于訓練和教育新開發者。你不知道有多少雙眼睛在關注著討論；即使大多數人不會參與，仍然可能有很多人在靜靜的跟蹤，收集軟件的信息。?討論會訓練你如何向不熟悉軟件的人們解釋技術問題。這種技巧需要練習，你不能從已經知道你所知道的人那里獲得這種練習。?之后，討論和結論將會一直存放在公共歸檔中，可以保證以后的討論不會回到同樣的步驟中。見Chapter 6, 交流的the section called “歸檔的顯著使用”。
最后，很有可能某個人會提出一個你從想到過的好主意，給對話帶來真正的貢獻。很難說這有多大的可能；這僅僅由代碼的復雜程度和需求的專業程度決定。但是如果允許我使用軼事作為證據，我會證明這樣做比直覺所期望的結果更好。在Subversion項目，我們（創始人）相信我們面對的是一組深入而復雜的問題，為此我們痛苦思考了幾個月，我們很明確的懷疑在新建立的郵件列表中的會有任何人做出真正的貢獻。所以我們選擇了一條比較懶惰的方式，開始通過私下郵件討論技術想法，直到項目的一個觀察者嗅出了問題，并要求將討論公開。眨了眨眼我們這樣做了—后來的結果讓我們十分驚訝，我們很快便獲得了許多有見地的回復和建議。大多數情況下人們提供的想法都是我們從來沒有想到的。結果是郵件列表中一下子多了許多非常英明的人；他們只是在等待正確的誘餌。可以肯定的是公開討論比私下討論會保持更長的時間，也能得到更多的產出，花費額外的時間是值得的。
我們不必把問題總結為：“團結就是力量”（我們已經見過許多更成功的團隊），但可以確認的是有一些事情適于在團隊中完成。首先是有了大量的審閱；其次是快速產生大量的想法。想法的質量由其所針對的思想決定，當然，在你用挑戰性的問題刺激他們之前，你無法判斷這些思考者是那種人。
當然，也有許多討論必須在私下進行，通過此書我們會看到這種例子。但是我們有一個指導原則如果沒有保持秘密的原因，那就公開進行。
要想使之發生，我們需要行動。僅僅保證自己所有的通告公開是不夠的。你也需要勸說其他人放棄不必要的私下討論。如果某個人嘗試開始沒有必要的私下討論，你要義不容辭的立刻進行恰當的元討論。在你將討論成功的引入公開場所之前，不要對原始主題做出任何回復，或者去確定私下進行是否必須。如果你一貫如此，人們會很快會意，并開始首選公開論壇進行討論。
[1]?TiDB Internals:?https://internals.tidb.io/[2]?ZoomQuiet:?https://github.com/ZoomQuiet[3]?調查:?https://lists.tidb.io/g/contributors/topic/survey_what_is_a_good/82016508[4]?橋接即時通信工具的方案:?https://internals.tidb.io/t/topic/382[5]?The Apache Way:?https://www.apache.org/theapacheway/index.html[6]?GitHub Discussion:?https://docs.github.com/en/discussions[7]?CockroachDB:?https://github.com/cockroachdb/cockroach/discussions[8]?TiDB Dev Guide:?https://pingcap.github.io/tidb-dev-guide/[9]?Contribute to TiDB:?https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/introduction.html[10]?Restructure Tests:?https://github.com/pingcap/tidb/issues/26022[11]?Move parser back to pingcap/tidb:?https://github.com/pingcap/tidb/pull/28015[12]?AskTUG:?http://asktug.com/[13]?Producing Open Source Software:?https://producingoss.com/
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
