開源社區在哪裏？
今年我積累了些爲 GitHub 項目建設開源社區的經驗，常在思考這個問題。
最近，GitHub 推出了一項新功能，才讓我確定答案：對於一個 GitHub 的開源項目，它的社區就在 GitHub 上。
你也許覺得我在說廢話。
如果你這麼想，請聽我細細道來。
GitHub 上的新社區
“世界各地的人們都在擁抱開源和 GitHub。GitHub 不僅是代碼開發者的家，也成了各行各業的人們工作、學習、與社區互動、爲開源作貢獻的平臺。” —— GitHub 2020 年度報告
GitHub 是全球最大的開發者平臺，也是一個社區型的代碼項目協作平臺。
GitHub 的最新數據顯示，GitHub 在全球範圍內已有 5600 萬開發者用戶（中國用戶數位列第二，僅次於美國），近一年內產生了 19 億次貢獻。
這些貢獻的大多數，都來自開源社區。
開源，意味着同社區一起互動、學習、創造。
但 GitHub 是否適合作爲開源社區的大本營，組織社區成員進行互動、學習、創造？
無論你是項目的維護者還是使用者，都值得好好琢磨下這個問題。
如果你是項目的維護者，請問問自己：
- 你如何與社區對話？
- 社區成員如何與彼此對話？
- 你如何組織社區成員、完成更卓越的貢獻？
如果你是項目的使用者，請問問自己：
- 你的問題如何得到快速響應和解答？
- 你如何獲知該項目的最新動態、公告？
- 你如何與項目建立連接、做出力所能及的貢獻？
爲了做到這些，開源社區至少要具備以下基礎設施：
- 互動交流區
- 官方公告欄
- 社區知識庫
此前，GitHub 只提供議題（issue）、拉取請求（Pull Request）功能進行社區的互動交流。這兩種頁面都是線性組織的，適合快速合併代碼，但不適合多線程的溝通和社區知識庫的積累。而 GitHub 的 wiki 功能則相對較重，不適合碎片化優質內容的積累。
因此得出結論：
此前，GitHub 本身並不能很好地支撐開源社區的基礎設施建設。
這就導致了，圍繞項目產生的社區分散在互聯網各個區域。
拿一個代碼項目舉例：
- 項目的日常交流可能在 Gitter（一款即時聊天工具）、Slack、微信上
- 項目使用問題可能在 Stack Overflow、GitHub Issues 上
- 具體事項的討論可能在自建的論壇、Google 羣組上
- 社區相關的公告可能在維基、公司官網的新聞公告上……
如此“分佈式”的互動，容易導致社區的鬆散、無組織：一方面很多優質的討論和內容流落在外，另一方面爲新成員融入社區平添了許多摩擦。
如果你也有同感，現在可以鬆一口氣了。
因爲 GitHub 近期提供了討論（Discussions）功能，將“流落在外”的社區重新聚集起來，帶回了離源代碼更近的地方——項目倉庫 （repository）本身。
Discussions 功能簡介
“軟件社區的成員不只在一起寫代碼。他們還能一起頭腦風暴出新想法、新功能，幫助小白用戶快速上手，探索軟件的最佳實踐。社區需要自己的互動空間，這就是 Discussions 的意義。” —— 某 Hacker News 用戶
“討論”是 GitHub 今年年初推出的內測功能，當時官方選取了幾個項目做內測，包括 Next.js、Tailwind CSS、Office 365 CLI 等。
該功能於 12 月 8 號正式開放公測。
目前，每個公共倉庫都可以在 “Settings/Options/Features/Discussions” 處啓用該功能。
啓用討論功能的設置頁面
啓用後，“討論”作爲倉庫的一個獨立區域（下圖紅框位置），用於社區成員問答互動，類似於論壇。
Next.js 項目的討論首頁
單個討論頁面與議題頁面很相像，但討論還提供以下新功能：
- 支持自定義討論分類（比如可以有問答區、腦洞區、新項目展示區、求助區等）
- 支持將已有的議題遷移成討論
- 支持將某個回覆標記爲答案（類似於 Stack Overflow）
- 支持開啓對話的線索（類似於 Slack）
- 支持在討論首頁固定最多 4 個討論（可作爲官方公告欄）
討論的利與弊
對於項目維護者來說，“討論”的好處如下：
- 補全 GitHub 的社交性，與倉庫的其他功能緊密結合，共建完整的社區
收集 bug 和功能需求用 議題（Issues）、接受貢獻用拉取請求（ Pull Requests）、項目協作及管理用項目（ Projects ）和看板（Kanban）、代碼持續集成部署用動作（ Actions）、接受社區贊助用贊助者（ Sponsors）、發佈重要文檔用維基（ wiki），社區公告及互動用討論（ Discussions），一條完整的社區鏈路似乎已然補全了 :-) - 可以把除了 bug 報告和新功能需求的議題通通遷移到討論，進行分類管理，減少議題中的噪音
一些大型倉庫動輒就有上千議題，包括 bug 報告、新功能需求、用戶的使用問題、已有功能的討論等等。議題種類混亂，極易堆積，管理起來十分痛苦。如果能將部分議題遷移到討論，合理分類，藉助社區的力量解決問題，或許能減輕項目維護者的負擔。 - 討論版塊作爲社區入口，方便新人瞭解項目情況、社區文化
可以在討論版塊內放置項目的上手資料、貢獻指南、代碼規範、博客鏈接甚至公開適配器列表、數據表現等等，鼓勵社區成員在離源碼更近的地方學習、交流、產生連接、積累知識庫。
比如下圖是 Next.js 項目專門建的討論頁面，鼓勵社區主動完善適配器列表：
適配器列表所在的討論頁面
討論的壞處如下：
- 對於業餘項目的維護者來說，啓用天倫可能會加重他們的負擔
討論降低了互動的門檻，當更多的討論湧入，維護者的工作就更多了。 - 與議題的區分有些不明晰，項目維護者在初期可能要耗費一些精力來教育用戶，分清兩種功能的定位
而對於項目使用者來說，目前來看該功能有利無弊。
用戶的問題解決路徑原來也許是這樣的：
項目使用過程中碰到問題 -> Google -> Stack Overflow 或 GitHub 議題 -> 如果沒有答案，則新建問題
現在也許是這樣的：
項目使用過程中碰到問題 -> 搜索項目的討論 -> 如果沒有答案，則新建討論
討論慢慢會變成用戶第一時間尋求解決方案的地方，因爲這裏就是項目的專有社區。
GitHub 社區新形態展望
好的社區不僅要讓貢獻者持續增長和參與，還必須儘量減輕項目維護者的負擔。 —— GitHub 2020 年度報告
有了討論，未來的 GitHub 開源社區將呈現何種新形態？
這個問題目前很難回答，但我們可以看看從年初就開始內測討論功能的項目，或許能一探未來的趨勢。
今年 3 月，Office 365 CLI 項目宣佈解散他們的 Gitter 論壇，以後所有的討論都遷移至討論：
Office 365 CLI 解散 Gitter 論壇的官推
Next.js 倉庫今年 1 月開始使用討論，截至 10 月，已使用超過 3000 個桃花進行交流協作。並且，在過去的一年中，向倉庫做出貢獻的人中近半數都使用了討論。（數據來自 GitHub 2020 年度報告）
Next.js 倉庫甚至將 RFC 從議題遷至了討論，方便社區成員第一時間參與到新功能的討論中（瞧瞧評論區的反響，這纔是“活生生”、“有人氣”的社區啊！）：
討論版塊下創建的 RFC 頁面
目前 Next.js 倉庫首頁對社區的導流只有兩處：一個是 GitHub 討論，另一個是 Discord（輕量的聊天應用）。前者用於提問、分享新想法和新項目，後者用於與社區成員聊天。
Next.js 倉庫首頁對社區的引流
從上面的例子可以看出，社區正朝着統一化的方向在發展。統一平臺的社區管理方式，不僅能降低社區成員的參與成本，也能在一定程度上減輕項目維護者的運營壓力。
因此，我斗膽在這展望下日後的開源社區形態：
All in GitHub
- GitHub 議題：用於收集 bug 和待開發的新功能
- GitHub 討論：用於發佈三類信息 (1) 新功能的 RFC；(2) 幫助和公告信息，如貢獻指南、代碼規範、社區活動的宣傳等；(3) 日常的問答與交流
- GitHub 項目：用於追蹤開發進度、社區成員可以參與協作
- GitHub 拉取請求：用於提交代碼、社區成員可以參與審校
討論讓項目信息的發佈變得更快捷、集中、透明。社區成員留下的每一條問答，都是對社區知識庫的貢獻；他們在 RFC 討論區留下的每一個👍，都真正參與了項目的決策。
每個開源項目的作者，或許都夢想過擁有一個活躍、自治、貢獻度高的開源社區，加速項目的高質量迭代。
現在，我們離這個夢，似乎又更近了一步。
結語：GitHub 的野心
毋庸置疑，GitHub 是一款非常棒的產品。自 2018 年被微軟收購後，推出了更多走心、實用的功能。
作爲一名 GitHub 的產品粉，我由衷地感到欣慰，GitHub 仍在積極地重新定義產品的邊界，不斷推出讓千萬用戶眼前一亮的新功能。
但在 Hacker News 上，許多開發者對 GitHub 王國的「版塊擴張」表示擔憂：
- 2008 年，新功能 Pages 發佈，與諸多網站託管平臺對線
- 2016 年，新功能 Projects 發佈，與 Trello、Waffle 對線
- 2018 年，新功能 Actions 發佈，與 Travis、CircleCI 對線
- 2019 年，新功能 Sponsors 發佈，與 Patreon 對線
- 2020 年，新功能 Discussions 發佈，與 Stack Overflow 對線
GitHub 在性能和 UI 方面做得很好，用戶很難抗拒在同一平臺上把這些事全做了。但在長遠看來，平臺建立壟斷性優勢，對用戶來說未必是件好事。
這也許確實是 GitHub 的野心。
不過，站在 GitHub 的角度無可厚非，站在用戶的角度有利有弊。
目前看來，對於普通的項目作者和用戶，利肯定遠遠大於弊。至於未來如何，讓我們拭目以待吧。
