開源項目的首要挑戰是找出最佳的貢獻者協作方式 -- Jono Bacon

本文導航

• -結構化和非結構化 …… 14%

• -記錄的影響 …… 41%

• -你想喝點什麼 …… 73%

編譯自： https://opensource.com/article/17/5/much-ado-about-communication

作者： Jono Bacon

譯者： geekpi

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

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

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

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

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

結構化和非結構化

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

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

結構化渠道在每個單獨的溝通單元中都有非常具體的重點。例子如：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 嗎？」 （好吧，也許問最後一個問題的只有我。）

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

你想喝點什麼

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

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

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

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

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

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

（題圖： Opensource.com）

作者簡介：

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

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

作者：Jono Bacon[4] 譯者：geekpi 校對：jasminepeng

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

• [1]: 幫助其建立內外部社區 - http://www.jonobaconconsulting.com/

• [2]: 網站 - http://www.jonobacon.com/

• [3]: jono@jonobacon.com - mailto:jono@jonobacon.com

• [4]: Jono Bacon - https://opensource.com/users/jonobacon

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！