文檔教程【免費下載鏈接】opensource.guide Community guides for open source creators項目地址https://gitcode.com/gh_mirrors/op/opensource.guide點擊查看免費下載本篇指南基于開源社區(qū)知識庫Open Source Guides的《Wie zu Open Source beitragen?》如何為開源做貢獻一文面向首次接觸開源的初學者與希望持續(xù)參與的老手系統(tǒng)講解從為什么貢獻到如何找到項目如何提交貢獻提交之后會發(fā)生什么的完整路徑。讀完本文你將掌握一套可立即上手的開源協(xié)作方法論既能以非代碼方式文檔、設(shè)計、翻譯、組織切入社區(qū)也能規(guī)范地發(fā)起 Issue、提交 Pull Request并正確應(yīng)對貢獻被忽略、被要求修改或被拒絕的各種結(jié)局。為什么參與開源貢獻參與開源是一條回報豐厚的成長路徑可以讓你在幾乎任何領(lǐng)域?qū)W習、教授并積累經(jīng)驗。人們投身開源的理由多種多樣原文歸納為七個層面改進你依賴的軟件很多貢獻者最初就是所貢獻軟件的用戶。當你發(fā)現(xiàn)一個 Bug 時可以先閱讀源碼判斷能否自行修補把補丁回饋給項目是讓同事以及更新到下一版本后的你自己都能受益的最佳方式。打磨既有技能無論是編程、界面設(shè)計、平面設(shè)計、寫作還是組織統(tǒng)籌只要你想找練習機會開源項目里總有適合你的任務(wù)。結(jié)識志同道合的人擁有溫暖、友好社區(qū)的開源項目能讓人們多年持續(xù)參與許多人因此結(jié)下終身友誼——無論是會議上相遇還是深夜在線暢聊。尋找導師并指導他人與他人協(xié)作意味著既要解釋自己的做法也要向他人求助。教與學對參與各方都是充滿成就感的活動。積累公開成果、塑造聲譽與職業(yè)你的全部開源工作本質(zhì)上是公開的天然形成一份可以隨身攜帶、隨時展示能力的作品集。鍛煉人際技能開源提供沖突解決、團隊組織、任務(wù)優(yōu)先級管理等領(lǐng)導力與管理技能的實踐機會。小改動也能帶來掌控感參與開源不必成為終身事業(yè)?？吹骄W(wǎng)站上的錯別字并親自修復這種自己動手改善世界的體驗本身就令人滿足。貢獻遠不止寫代碼八種非代碼貢獻路徑對開源貢獻最常見的誤解是必須貢獻代碼。事實上項目中往往是最容易被忽視的非代碼部分最缺人手主動參與這些方面是對項目的巨大幫助。你的特長可以做的貢獻策劃活動組織關(guān)于項目的 Workshop 或 Meetup籌辦項目會議幫助社區(qū)成員找到合適的會議并提交演講提案設(shè)計重構(gòu)布局以提升易用性開展用戶研究優(yōu)化導航與菜單制定統(tǒng)一視覺風格的設(shè)計規(guī)范為 T 恤或新 Logo 創(chuàng)作素材寫作撰寫與改進項目文檔整理應(yīng)用示例合集為項目創(chuàng)辦 Newsletter 或精選郵件列表內(nèi)容編寫教程翻譯項目文檔組織關(guān)聯(lián)重復 Issue、建議新標簽以保持 Issue 整潔梳理舊 Issue 并建議關(guān)閉對新 Issue 提出澄清性問題推動討論編程認領(lǐng)可解決的開放 Issue主動提出實現(xiàn)新功能自動化項目搭建流程改進工具鏈與測試幫助他人在 Stack Overflow、Reddit 等平臺回答項目相關(guān)問題回答開放 Issue 中的提問協(xié)助管理討論區(qū)或溝通渠道幫他人寫代碼評審他人的 Pull Request編寫項目使用教程為其他貢獻者提供結(jié)對指導非軟件項目開源并不限于軟件——書籍、菜譜、清單、課程等都可以是開源項目即使你是軟件開發(fā)者從一個不涉及代碼的文檔類項目切入往往壓力更小協(xié)作過程本身就能建立信心與經(jīng)驗。關(guān)于文檔貢獻的分量本項目就是最好的例證Open Source Guides 站點的最大貢獻需求恰恰是編輯修正與翻譯見 CONTRIBUTING.md并在 docs/translations.md 中建立了完整的多語言翻譯工作流。熟悉一個新項目解剖一個開源項目在深入提建議之前先學會讀懂現(xiàn)場否則就像在一群正討論金魚的人中間突然聊起羊駝。理解社區(qū)角色、文檔結(jié)構(gòu)與協(xié)作工具能幫你快速適應(yīng)任何新項目。社區(qū)角色一個典型的開源項目包含以下角色作者Author創(chuàng)建項目的個人或組織。所有者Owner對組織或倉庫擁有管理權(quán)的人不一定是原作者。維護者Maintainers負責推動項目愿景與管理組織事務(wù)的貢獻者可能同時是作者或所有者。貢獻者Contributors所有為項目做出過回饋的人。社區(qū)成員Community Members使用項目的人可能活躍在討論中并表達對項目方向的看法。更大的項目還會有工具鏈、Issue 分診、社區(qū)運營、活動組織等分工的小組或工作組可在項目網(wǎng)站的 Team 頁面或倉庫的治理文檔中找到。倉庫頂層文檔項目的頂層目錄通常羅列著以下關(guān)鍵文件它們共同構(gòu)成項目說明書LICENSE許可證按定義每個開源項目都必須有開源許可證沒有許可證就不是開源項目。本項目即采用 CC-BY-4.0。README歡迎新社區(qū)成員的使用說明書說明項目為什么有用、如何上手。項目根目錄的 README.md 即承擔此角色。CONTRIBUTING與 README 教人使用不同貢獻文檔教人如何貢獻說明需要哪些類型的貢獻以及流程如何運轉(zhuǎn)。其存在本身就標志著項目歡迎貢獻——本項目的 CONTRIBUTING.md 列出了貢獻類型、行為準則、環(huán)境搭建與風格要求。CODE_OF_CONDUCT行為準則為參與者行為設(shè)定基本規(guī)則營造友好、歡迎的環(huán)境。項目根目錄的 CODE_OF_CONDUCT.md 即屬此類。其他文檔大型項目還會有教程、實操指南或治理政策。組織討論的工具Issue 追蹤器討論與項目相關(guān)的問題。Pull Requests討論與評審進行中的變更。討論區(qū)或郵件列表部分項目用它承載How do I...或What do you think about...這類會話式話題另一些項目則把所有對話都放在 Issue 追蹤器。同步聊天頻道Slack、IRC 等用于日常交流、協(xié)作與快速問答。尋找可貢獻的項目如果你從未參與過開源記住肯尼迪的名言不要問國家能為你做什么問問你能為國家做什么。貢獻發(fā)生在各種層級、各類項目上不必過度糾結(jié)第一份貢獻長什么樣。從你已經(jīng)在用或想用的項目出發(fā)一旦產(chǎn)生這里能更好的念頭就付諸行動。一個值得注意的數(shù)據(jù)研究顯示開源中28% 的零散貢獻屬于文檔類如錯別字修正、格式調(diào)整、翻譯這意味著讀 README 時發(fā)現(xiàn)一個失效鏈接或錯別字正是最典型的入門起點。尋找可認領(lǐng)的現(xiàn)成 Issue 時可以在倉庫主頁 URL 末尾加上/contribute每個開源項目都有展示新手友好 Issue 的頁面。此外還有若干專門的新手項目發(fā)現(xiàn)渠道GitHub Explore、Open Source Friday、First Timers Only、CodeTriage、24 Pull Requests、Up For Grabs、First Contributions 等。翻譯就是本項目最實際的入門路徑之一docs/translations.md 詳細說明了從_data/locales/en.yml復制出目標語言文件、在_articles/下建立語言目錄如_articles/de/、運行script/test校驗、最后發(fā)起 Pull Request 的完整流程——本文所對應(yīng)的德語版 _articles/de/how-to-contribute.md 正是該流程的產(chǎn)物。提交貢獻前的檢查清單找到心儀項目后先快速判斷它是否適合接受新貢獻避免辛苦付之東流。按是否符合開源定義、是否活躍接受貢獻、是否歡迎新人三個維度逐項核查是否符合開源定義項目是否帶許可證通常是倉庫根目錄的 LICENSE 文件項目是否活躍接受貢獻查看主分支的提交活動最近一次提交是什么時候項目有多少貢獻者人們提交的頻率如何GitHub 可在頂部欄 Commits 中查看有多少開放 Issue維護者對新 Issue 回應(yīng)快嗎Issue 上的討論是否活躍Issue 是否新近提出Issue 有沒有在持續(xù)關(guān)閉GitHub 可在 Issues 頁的 closed 標簽查看有多少開放 Pull Request維護者對新 PR 回應(yīng)快嗎PR 的討論是否活躍PR 是否新近提出最近有 PR 被合并嗎項目是否友好歡迎維護者是否以有幫助的方式回應(yīng) Issue 中的提問人們在 Issue、討論區(qū)、聊天頻道中是否友善PR 是否會被評審維護者是否感謝貢獻者經(jīng)驗之談看到超長討論帖時抽樣檢查核心開發(fā)者姍姍來遲的回復——他們是建設(shè)性地總結(jié)并推動討論走向決策、同時保持禮貌還是充斥著無休止的罵戰(zhàn)后者往往意味著精力浪費在爭吵而非開發(fā)上。如何提交貢獻有效溝通的六條原則無論是一次性貢獻者還是試圖融入社區(qū)與他人協(xié)作都是開源中最重要的一項技能。在發(fā)起 Issue、PR 或提問前記住以下原則說明背景遇到錯誤時說清楚你在做什么、如何復現(xiàn)提新想法時解釋它對項目而不只是對你的價值。 當 Y 時 X 不會發(fā)生 X 壞了請修復提前做好功課求助前先查過 README、文檔、Issue開放與關(guān)閉的、郵件列表和互聯(lián)網(wǎng)。人們會欣賞你展現(xiàn)出的學習誠意。 我不確定如何實現(xiàn) X查過幫助文檔但沒有提及。 X 該怎么做請求簡短直接每條貢獻無論多簡單都需要他人評審許多項目的需求遠超人力。言簡意賅能提高被幫助的概率。保持溝通公開除非涉及敏感信息安全漏洞或嚴重違規(guī)不要私下聯(lián)系維護者。公開交流能讓更多人受益討論本身就是一種貢獻。提問是被允許的但要有耐心每個人都是新手起步老貢獻者接觸新項目也要時間長期維護者同樣不熟悉項目每個角落。請給他們你期望得到的耐心。尊重社區(qū)決策你的想法可能與社區(qū)優(yōu)先級或愿景相左。可以討論與尋求折中但維護者需要為決策負責更久若不同意方向永遠可以 fork 自建或另起項目。保持風度開源匯集了來自全球、跨語言文化的協(xié)作者書面溝通難以傳達語氣。假設(shè)對話中善意為先禮貌地反駁、追問背景或澄清立場都沒問題——讓互聯(lián)網(wǎng)因你而變得更好。動手前先收集上下文先快速確認你的想法未被討論過瀏覽 README、Issue開放與關(guān)閉、郵件列表和 Stack Overflow幾個關(guān)鍵詞的快速搜索就能避免大量重復勞動。確認無果后按項目所在平臺選擇溝通方式Issue類似發(fā)起對話與討論Pull Request是開始動手解決問題單純的流程澄清類提問則適合 Stack Overflow、IRC、Slack 等頻道。打開 Issue 或 PR 之前務(wù)必閱讀項目的貢獻文檔通常是 CONTRIBUTING 文件或 README 中的相關(guān)章節(jié)確認是否需要遵循模板、強制使用測試等要求。若要提交實質(zhì)性貢獻先開 Issue 征求同意再動手同時可以持續(xù) Watch 項目GitHub 上點擊 Watch 可收到所有對話通知在動手前熟悉社區(qū)成員。創(chuàng)建 Issue以下情況通常應(yīng)當創(chuàng)建 Issue報告自己無法解決的錯誤討論高層話題或想法如社區(qū)、愿景、政策提議新功能或其他項目想法。Issue 溝通技巧看到想認領(lǐng)的開放 Issue先留言表明我來處理減少他人重復勞動Issue 開得較早它可能已在別處處理或已解決先留言確認再開工自己開的 Issue 后來找到了答案留言告知答案然后關(guān)閉 Issue——記錄這個結(jié)果本身也是貢獻。創(chuàng)建 Pull Request以下情況通常應(yīng)當打開 PR提交瑣碎修正錯別字、失效鏈接、明顯錯誤開始實現(xiàn)已經(jīng)過 Issue 討論、被認可的工作。PR 不必代表完工盡早打開讓其他人圍觀并反饋通常更好可在主題中標注 WIPWork in Progress或 Draft。以 GitHub 上的流程為例標準操作如下Fork 倉庫并克隆到本地將本地倉庫與原 upstream 倉庫關(guān)聯(lián)為 remote頻繁從 upstream 拉取更新讓提交 PR 時更少出現(xiàn)合并沖突。為修改創(chuàng)建分支如your-change。在 PR 中引用相關(guān) Issue或支撐文檔例如 Closes #37。包含修改前后的截圖若改動涉及 HTML/CSS 差異將圖片拖入 PR 正文。測試你的改動運行既有測試并在需要時新增測試確保不破壞現(xiàn)有項目。遵循項目代碼風格縮進、分號、注釋習慣可能與你的倉庫不同但遵循它能讓維護者更易合并、他人更易理解維護。如果是第一次提 PR可以先在 First Contributions 這類練習倉庫中演練 fork、分支、提交與 PR 的完整流程。提交之后會發(fā)生什么貢獻提交后可能出現(xiàn)四種結(jié)局原文都給出了應(yīng)對建議 無人回應(yīng)貢獻前應(yīng)已核查過項目活躍度但即便活躍項目也可能石沉大海。超過一周無回應(yīng)時禮貌地在原線程中請人評審可用提及合適的評審人但不要私下聯(lián)系。若提醒后仍無回應(yīng)可能永遠不會有人回復——不必氣餒原因往往超出你的控制。換個項目或換種方式繼續(xù)貢獻這也說明在社區(qū)回應(yīng)之前不宜在單個貢獻上投入過多時間。 被要求修改被要求調(diào)整想法范圍或修改代碼很常見。請積極響應(yīng)——對方花時間評審了你的貢獻開個 PR 就消失是不禮貌的。不會改就研究問題再求助若因時間、環(huán)境變化無法繼續(xù)主動告知維護者以便把 Issue 開放給其他人接手。 未被接受貢獻可能最終不被接受。若不明白原因完全可以向維護者請求反饋與澄清但最終要尊重其決定不要爭吵或敵對。不滿意時fork 出自己的版本永遠是合法選項。 被接受恭喜你成功完成了一次開源貢獻。結(jié)語Issue 一個、PR 一個地改變世界無論你剛完成第一份貢獻還是正在尋找新的貢獻方式希望本文能激勵你邁出下一步。即使貢獻未被接受也別忘了在維護者付出努力時表達感謝。開源正是由你這樣的人一次一個 Issue、一次一個 Pull Request、一條評論或一個擊掌構(gòu)建起來的——本倉庫 CONTRIBUTING.md、docs/translations.md、docs/styleguide.md 與 test/lint_test.rb 中的自動檢查腳本正是如何貢獻方法論的真實落地隨時歡迎你對照實踐。贊分享文檔教程【免費下載鏈接】opensource.guide Community guides for open source creators項目地址https://gitcode.com/gh_mirrors/op/opensource.guide點擊查看免費下載相關(guān)推薦modAL貝葉斯優(yōu)化實戰(zhàn)指南三步實現(xiàn)智能超參數(shù)調(diào)優(yōu)modAL貝葉斯優(yōu)化實戰(zhàn)指南三步實現(xiàn)智能超參數(shù)調(diào)優(yōu) 你是否曾為機器學習模型的超參數(shù)調(diào)優(yōu)而煩惱傳統(tǒng)的網(wǎng)格搜索耗時耗力隨機搜索又不夠高效。今天我們將深入探討如WhatsNewKit項目貢獻指南如何為開源社區(qū)貢獻力量WhatsNewKit項目貢獻指南如何為開源社區(qū)貢獻力量 WhatsNewKit是一個強大的Swift包專門用于在iOS和macOS應(yīng)用中優(yōu)雅地展示新功能更DPM-Solver支持的4種模型類型深度解析如何選擇最適合你的擴散模型DPM Solver支持的4種模型類型深度解析如何選擇最適合你的擴散模型 DPM Solver是一個專為擴散概率模型Diffusion Probabilis上一篇告別黑箱訓練threestudio中TensorBoard可視化實戰(zhàn)指南下一篇如何使用 Keyviz 提升代碼審查效率完整配置指南與實用技巧創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考