關於開源專案如何選擇溝通渠道的思考

開源專案的首要挑戰是找出最佳的貢獻者協作方式

開源專案要面對的首要挑戰之一是如何在貢獻者之間溝通。這裡有很多的選擇：論壇、聊天頻道、工單（issue）、郵件列表、拉取請求（pull request）等等。我們該選擇哪個合適的來使用，我們又該如何做呢？

令人遺憾的是，專案本身往往不願做出約束性的決定，而是選擇“上述所有”。這就導致了一個支離破碎的社群：有些人使用 Slack/Mattermost/IRC，而有些人使用論壇，有些使用郵件列表，有些則存在於工單之中，很少有人能夠讀到所有這些途徑的內容。

在我幫助其建立內外部社群的組織中，這是一個常見的問題。我們會選擇哪個渠道，以及出於什麼目的？另外，何時可以對它們之一說不呢？

這就是我想在此處深度探討的。

結構化和非結構化

我並不是個聰明人。因此，我傾向於將問題分成小的部分，這樣我可以更好地理解它們。類似地，我傾向於將一個情景中各種選擇拆解成更小的部分，來更好地理解它們的目的。我在溝通渠道的選擇上也使用這種方法。

我認為有兩大溝通渠道的分類：結構化和非結構化。

結構化渠道在每個單獨的溝通單元中都有非常具體的重點。例子如：GitHub / GitLab /Jira 的工單（issue）。一個工單是與 bug 或功能有關的一個非常具體的資訊。在初始的工單帖子釋出之後引發的系列討論中，通常非常集中在該特定話題上，並會有一個結果（比如 bugfix 或者一個功能的最終計劃）。結果通常都反映在狀態（例如 “FIXED”、“WONTFIX” 或 “INVALID”）中。這意味著你可以瞭解溝通的始末，而無需閱讀中間的內容。

類似的，拉取/合併請求也是結構化的。它們集中在特定型別（通常是程式碼）的貢獻上。在最初的拉取/合併請求後，討論會非常集中在一個結果上：讓貢獻符合要求，且合併入程式碼庫中。

另一個例子是 StackOverflow/AskBot 這類的問答帖子。這些帖子以一個問題開始，接著被編輯以及回覆來提供對這個問題的精確答案。

透過這些結構化機制，通常幾乎不會偏離其本來結構。你不會在工單、拉取請求或問答話題上看到有人問別人他們的孩子/貓/狗/家人在做什麼。偏離話題在社群是不可接受的，這是結構化媒體的力量的一部分：它是集中和（通常）高效的。

反之，非結構化媒體包括聊天頻道和論壇。在這些環境中，通常會有一個主題（例如頻道或分論壇的主題），但是其中的會話與特定結果或結論的關係要小得多，而且通常情況下可能會更普遍。例如，在開發者郵件列表中，你會看到一系列討論，包括一般問題、新功能的想法、架構爭論以及與社群自身運營相關的討論。每一個討論都希望讓參與者保持對話的焦點、主題和工作效率。但你可以想象，情況往往不是這樣的, 這種討論可能會偏離一個富有成效的結果。

記錄的影響

除了結構化和非結構化溝通的微妙不同外，所記錄的內容以及它們如何搜尋的所帶來的影響也很重要。

典型的，所有的結構化渠道都是記錄的。人們可以參考以前的 bug，來自 StackOverflow 的問題可以被反覆地重新利用。你可以搜尋一些東西，即使有很多討論、常見問題、拉取請求或者提問，都會被更新以反映最終結論。

這是一個重點：我們希望能夠快速、輕鬆地挖掘舊問題/提問/拉取請求等，並連結到它們、引用它們。這裡的一個關鍵部分是我們把這個內容轉換成可以引用的材料，從而可以用來教育和告知人們以前的知識。隨著社群的發展，我們的結構化溝通成為一種知識庫，可以透過以往的經驗來告知未來。

而非結構化溝通變得越來越糟。一方面，論壇的搜尋通常都簡單高效，但是它們當然充滿了非結構化的對話，所以你正在尋找的東西可能被埋在討論之中。例如，許多社群使用論壇作為支援工具。雖然這是一個更強大的平臺，但是問題在於，一個問題的答案可能是在 16 樓或者 340 樓中有回覆。隨著越來越多的資訊來源（比如 Twitter）的轟炸，我們越來越不耐煩地閱讀大量的材料，這對於非結構化媒體來說可能是一個問題。

一個有趣的特定案例是實時聊天。歷史上，很多年來，IRC 為實時聊天鋪平了道路，對於大多數 IRC 使用者而言很少有（如果有的話）記錄這些討論的念頭。的確，一些專案（比如 Ubuntu）記錄了 IRC 日誌，但是這通常不是有用的資源。如我的夥伴 Atwood 有一次跟我說的：“如果你不得不在聊天中搜尋一些東西時，你已經輸了。”

雖然 IRC 在記錄上有所不足，而 Slack 和 Mattermost 會好點。交流會被歸檔，但是問題仍舊存在：你為什麼會想在海量的聊天資訊中找出一個人提出的觀點呢？其他的渠道能更好地引用先前的討論。

不過，這的確創造了一個有趣的機會。聊天相比其他媒體有個一貫的好處是能體現這是個怎樣的人。結構化的渠道，甚至非結構化的渠道，如論壇和郵件列表，很少鼓勵閒聊。但聊天是的，聊天時你會問：“你週末怎麼樣？”、 “你見過這個遊戲嗎？”還有“你下週會看 Testament，Sepultura 和 Prong 嗎？” （好吧，也許問最後一個問題的只有我。）

因此，雖然實時聊天相比前面的那些方式也許更低效一些，但是它的確增進了人們的關係。

你想喝點什麼

因此，回到我們最初的對於開源社群的提問：我們要選擇哪個？

雖然這個答案對於不同的專案會不同，但我想在兩個層面思考。

首先，你通常應該優先考慮結構化溝通。這是完成有形工作的地方：問題/工單、拉取請求、問答討論等等。如果你資源有限，那麼專注在這些渠道上，你可以用較少的時間和金錢支出，獲得社群的高效產出。

再者，如果你熱衷於建立一個可以專注於工程、宣傳、翻譯、文件等方面的更廣泛的社群，那麼探究是否引入非結構化渠道就有意義了。 社群不僅僅是為了完成工作，也是為了建立關係和友誼，在工作中相互支援，幫助人們在社群中發展壯大。非結構化通訊是一個有用的工具。

當然，我只是在一個大的話題上淺談輒止。 不過我希望在如何評估和選擇溝通渠道的價值方面，為大家提供了一些辨析。記住，少即是多：不要被擁有所有的渠道的妄想而誘惑，否則你會得到一個支離破碎社群，就像一個空蕩蕩的餐廳一樣。

願原力與你同在，請讓我知道你進行的如何。你可以透過我的網站和郵箱 jono@jonobacon.com 聯絡到我。

（題圖： Opensource.com）

---

作者簡介：

Jono Bacon 是一名領先的社群管理者、演講者、作者和播客。他是 Jono Bacon Consulting 的創始人，提供社群策略/執行、開發者工作流程和其他服務。他以前曾擔任 GitHub、Canonical、XPRIZE、OpenAdvantage 的社群總監，併為很多組織曾經提供建議和諮詢。

---

via: https://opensource.com/article/17/5/much-ado-about-communication

作者：Jono Bacon 譯者：geekpi 校對：jasminepeng

本文由 LCTT 原創編譯，Linux中國 榮譽推出