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

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

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

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

我們如何溝通

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

開放會議

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

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

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

我們的 Zulip 聊天

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

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

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

文檔

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

項目和議題

關于我們的項目和議題管理，我們鼓勵通過多種方式做出貢獻，我們?yōu)樾率謱ｉT創(chuàng)建特定的議題，并嘗試讓項目的設置變得簡單。

多種貢獻的方式

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

我們提倡的貢獻類型有：

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

僅限新手的問題

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

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

簡單的項目設置

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

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

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

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

對于我們的大多數(shù)項目，我們還提供應用程序的實時體驗版本或打包版本，以便貢獻者無需設置即可測試項目。這有助于我們?yōu)槟切﹂_發(fā)設置不感興趣或不熟悉的貢獻者提供一種方式，來嘗試我們應用程序的最新版本，并通過報告發(fā)現(xiàn)的任何錯誤來做出貢獻。我們在 ??質量保證指南?? 中放了這些應用程序的鏈接。

開源計劃

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

開源黑客（OSH）

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

我們?yōu)檫@個計劃選取幾個項目，請導師們集思廣益為參與者創(chuàng)造議題。項目開始后參與者可以認領議題并開始作出貢獻。導師們會支持幫助并審查他們的貢獻。

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

開源大使

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

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

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

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

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

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

總結

這些計劃幫助我們提高了對開源貢獻和回饋的不同方式的認識。通過它們，我們發(fā)現(xiàn)志愿者通過管理項目和舉辦公開會議來提供幫助，這有助于管理社區(qū)并為我們的貢獻者提供指導。

盡管我們得到了貢獻者的良好反響，并幫助人們做出了他們的第一個貢獻，但我們仍有很大的改進空間。我們將繼續(xù)改進我們項目的設置和貢獻指南，以改善貢獻者的體驗。我們還將繼續(xù)專注于確保我們的組織始終擁有并推動不同類別的問題，促進包容性，以便任何有意愿做出貢獻的人都能出自己的一份力。