管理對新手友好的開源社區的三個步驟

當有人剛開始為開源做貢獻時，最好從對新手友好的故障和議題開始。但在他們修復故障之前，他們必須要能夠找到這類問題。作為一個開源項目的成員，你可以做很多事情來幫助新手找到為項目貢獻的方式。

鑒於此，AnitaB.org 開源社區優先考慮讓我們的社區做到對新手友好。我們提倡包容性，確保不同經驗和水平的貢獻者都可以參與進來，並且他們的貢獻不止限於跟編程有關。

我最近在 Upstream 2021，即 Tidelift 活動中介紹了我們在 AnitaB.org 上所做的一些社區工作，該活動啟動了「維護者周」，這是一個為期一周的開源維護者慶祝活動。在活動中我討論了我們策略的三個主要部分：

我們如何溝通
項目和議題
開源項目

我們如何溝通

透明度是開源的重要組成部分，我們將透明度原則應用於我們的溝通方式。實際上，這意味著我們所有的社區會議都是公開進行的，並且影響我們設置 Zulip 聊天的方式以及我們提供文檔的方式。

開放會議

任何人都可以加入我們的會議，並討論與我們社區相關的話題。他們可以參與討論或者旁聽。會議相關信息在我們的社區日曆中都可以找到。在這些通話中我們通常只使用語音聊天，我們發現這可以讓人們在參與時感覺更自在。

我們舉辦以項目為中心的會議和一些分類的會議。會議上，來自不同領域的人們可以討論同一個項目並幫助改進我們的流程。偶爾，我們會有「自由提問 Ask Me Anything （AMA）」會議，任何人都可以來問任何與開源相關的問題。

所有會議我們都會在共享文檔中進行記錄，並在我們的 Zulip 中共享摘要和文檔鏈接。

我們的 Zulip 聊天

開源 Zulip 聊天平台是我們的主要社區交流渠道，雖然我們也在 Github 的評論區討論議題和拉取請求 Pull Request （PR）。一般來說，我們禁用了私人消息以確保我們儘可能透明。對於這條規則，我們只有少數例外，那些私人聊天是管理員在處理我們運行程序的後勤工作所用的。我們發現這種方法更受歡迎，它還使我們能夠更清楚公共聊天中的違規行為。

我們在 Zulip 聊天室分享所有會議摘要，包括討論的要點、行動項目和文檔。這些聽起來好像是些顯而易見的要求，但我一直驚訝於很多開源項目並不提供會議筆記，所以 Zulip 可以讓那些沒有參加會議的人也隨時了解情況。

在 Zulip上，我們討論項目路線圖，回答社區的問題和疑問，並積極促進人們通過不同的方式方法和在不同的場景下做出自己的貢獻。有時我們為貢獻者的成就而慶祝 —— 無論是為了突出他們測試或者審查的第一個拉取請求，還是強調我們志願者所做的出色工作。

文檔

我們盡量保持關於我們流程的開放文檔，例如常見問題解答，以便這些社區成員可以按照自己的節奏和時間了解社區。這是為了讓他們在聯繫我們之前了解我們的工作方式以及我們從事的工作類型。

項目和議題

關於我們的項目和議題管理，我們鼓勵通過多種方式做出貢獻，我們為新手專門創建特定的議題，並嘗試讓項目的設置變得簡單。

多種貢獻的方式

我們努力創建需要不同貢獻的問題，例如文檔、測試、設計和外展。這是為了讓任何人 —— 無關他們的經驗水平和興趣領域 —— 都能做出貢獻。這樣能夠幫助社區參與進來，而且我們發現它使成員能夠從一些省力但有價值的任務開始一步步做出貢獻。

我們提倡的貢獻類型有：

不同複雜性的編程任務。
質量保證任務 —— 貢獻者可以測試我們的應用程序或拉取請求並報告錯誤。
社區成員可以參與討論的設計會議。此外，創建模型和重新設計我們應用程序某些部分的機會，並探索改進用戶體驗。
外展任務，我們主要在 Zulip 上推廣，我們建議在我們的 Medium 出版物上發表博客，介紹他們的開源經驗和他們的貢獻。
文檔任務，可以包括一般社區文檔或我們在 Docusaurus 上的項目文檔。

僅限新手的問題

我們將一些議題標記為「僅限新手」。這些問題適用於尚未為議題存儲庫做出貢獻的人。為議題做標籤還使我們能夠讓人們在貢獻者大量湧入時開始他們的開源之旅，例如，在谷歌編程之夏（GSoC）申請期間。

有時，這些可能是「唾手可得的果實」，可以讓他們熟悉作出貢獻和提交拉取請求的過程。

簡單的項目設置

我們也很在意為我們的項目提供新手友好的安裝設置。我們注意到最活躍的項目通常是最容易設置的。我們知道，為你不熟悉的項目做出貢獻可能需要付出很多努力並且關乎貢獻體驗的成敗。

我們嘗試提供有關如何在多個操作系統上運行我們項目的說明。在過去，我們有一些項目有單獨的說明，可以在 Unix 環境下運行，我們注意到貢獻者在 Windows 上運行這些項目有些困難。自那以後我們不斷進行改進，以避免貢獻者在 Zulip 上尋求幫助時出現混亂。

我們根據貢獻者的經驗，一直在改進我們最活躍的項目之一 mentorship-backend 的自述文件。新手在這個項目中遇到的困難之一是設置與配置電子郵件帳戶相關的部分環境變數，以使後台功能能夠發送電子郵件。但是，由於此功能對於本地開發並不重要，因此默認情況下，我們將電子郵件設置設為可選，以便將電子郵件列印到終端，而不是發送給用戶。這種方法仍然使貢獻者可以看到這些電子郵件。與此更改類似，我們將 SQLite 資料庫作為本地開發的默認設置，以避免對 Postgres 資料庫進行額外設置，雖然我們在部署版本中會使用到 Postgres。

我們注意到，一些貢獻者在為我們的 bridge-in-tech-backend 項目做出貢獻時覺得很困難，該項目的設置很複雜，並且包含的步驟比 mentorship-backend 多得多。自從我們在一個開源項目中注意到這一點以來，我們一直在探索如何改進其結構。

對於我們的大多數項目，我們還提供應用程序的實時體驗版本或打包版本，以便貢獻者無需設置即可測試項目。這有助於我們為那些對開發設置不感興趣或不熟悉的貢獻者提供一種方式，來嘗試我們應用程序的最新版本，並通過報告發現的任何錯誤來做出貢獻。我們在質量保證指南中放了這些應用程序的鏈接。

開源計劃

我們在社區中組織了兩個主要計劃：開源黑客（OSH）（一個為期一個月的項目）和 Open Source Ambassadors（一個為期六個月的項目）。

開源黑客（OSH）

在此計劃中，我們在多個類別的貢獻中創建議題 —— 文檔、編碼、外展、測試和設計（類似於谷歌的 Code-in 競賽）。參與者可以為每個類別至少貢獻一次並獲得電子證書。一個議題可能包含多個類別，並且無需合併拉取請求也能使貢獻有效。

我們為這個計劃選取幾個項目，請導師們集思廣益為參與者創造議題。項目開始後參與者可以認領議題並開始作出貢獻。導師們會支持幫助並審查他們的貢獻。

這種方法鼓勵貢獻的多樣性，並歡迎任何人，無論他們的編碼能力如何，都可以在友好和不怕出錯的環境中做出貢獻。

開源大使

在此計劃中，我們從社區中選擇大使，理想情況下他們將涵蓋我們旨在促進的每一類貢獻。至今該計劃已啟動了兩次。

該計劃旨在讓成員通過回答社區的議題、協助貢獻者參與並為他們指定的類別宣傳來幫助管理項目和計劃。

第一個計劃舉行時我們接受了所有的申請者。我們評估了社區成員的興趣所在，並為那些想要做出貢獻但最初不敢踏出第一步的人提供了一個體系。

第一個計劃的舉辦給了我們很多啟發。因為我們的活動中既有經驗豐富的開源貢獻者和社區成員，也有初來乍到缺乏經驗的新手，因此項目的執行要求管理員進行大量的管理工作。一些社區大使信心十足準備好進一步採取新措施，而其他大使則需要更多支持。到了第二個，我們決定縮減該計劃，只接受那些已經熟悉社區、可以領導倡議和項目並幫助我們培訓新人的貢獻者。

第二個計劃中形成了正反饋循環。那些在第一個計劃中還是新手的大使們，通過為上一個項目做出貢獻並且從項目經驗中學習之後能夠做到輕鬆帶領項目。

這種方法的改變使管理員能夠更加專註於支持大使團隊，幫助他們傳播我們的使命，並繼續讓我們的社區對新手友好，並指導更多人做出貢獻。