Github 開源項目貢獻指南：如何給開源項目作貢獻（上）

時間 2019-11-12

標籤 github 開源項目貢獻指南如何欄目 Git 简体版

原文原文鏈接

歡迎你們關注騰訊雲技術社區，咱們將爲你們推薦技術精品文章哦~html

來源：騰訊開源前端

本文是【Github開源項目貢獻指南】系列的第一章，原文【Open Source Guides——How to Contribute to Open Source】node

爲什麼要給開源項目作貢獻？

給[freenode]作貢獻幫助我學到了不少後來在大學和實際工做中用到的技能，我以爲給開源項目工做對個人幫助和對項目自己的幫助相差無幾。python

—@errietta [「Why I love contributing to open source software」]git

給開源項目作貢獻能夠說是在你能想象的領域上學習，傳授，累計經驗的最有效的方式！爲何人們要給開源項目作貢獻，緣由太多了！github

提升現有技能

無論是寫代碼，用戶界面的設計，圖形設計，寫做，或者是組織，若是你想找點練習作一作，在開源項目上你總能找到能勝任的任務。面試

認識和你有一樣愛好的人

氣氛融洽開放的開源項目會讓人數年以後仍然不忘回來看看（項目進展）。許多人在參與開源項目的過程當中結識了一輩子摯友，友誼在會議的互相照面和深夜的線上閒聊中漸漸造成。api

尋找導師或者教導別人

和他人一塊兒合做一個項目意味着你得解釋你是怎麼作事情的，同時尋求他人的幫助。學習和傳授知識的體驗對每一個參與其中的人來講都是使人愉快的體驗。ide

作一個公開的產品幫你贏得聲譽（和職業機會）

從開源項目的定義能夠知道，你全部的工做成果都應該公開，這意味着你免費得到了一個向衆人展現你能力的機會。工具

學習他人的技能

開源項目給參與其中的人們提供了鍛鍊領導力和管理能力的機會，好比解決衝突，組織團隊的成員，辨別工做的輕重緩急。

你有權作出改動，就算是很小的

你不須要成爲那種一直在給開源作貢獻的人。你有在網站上看見手誤嗎，並且但願有人能修正它。在一個開源項目中，你本身就能夠作到。開源幫助人們在生活和對世界的體驗上感受到更有力量，這自己確實是意見可喜的事情。

貢獻是什麼意思

若是你是一個剛剛開始的開源貢獻者，這個過程可能會讓你以爲很嚇人。如何找到正確的項目？你不知道怎麼貢獻代碼怎麼辦？若是改錯了怎麼辦？

沒必要擔憂！有不少參與開源項目的方法，和一些讓你走出困境的小技巧。

你不須要貢獻代碼

對開源貢獻的一個廣泛的誤解就是你得貢獻代碼。實際上，一般和代碼無關的部分纔是最容易忽視的：經過參與非代碼部分的貢獻會給項目帶來巨大的幫助。

我由於對 CocoaPods的貢獻而著名，可是大部分人都不知道我在這個工具自己的開發上並無作實質性的工做。我花在這個項目上的主要時間都用來整理文檔和宣傳品牌。

—–@orta

即便你是一個開發者，非代碼部分的貢獻是一個很好的方式讓你參與一個項目和認識社區的成員。創建這種關係會給你從事項目其餘部分工做的機會。

我第一次接觸 Python 開發團隊（又叫作 python-dev）是在2002年6月17號我給郵件列表發郵件讓他們接受個人補丁的時候。我迅速的發現的這個項目的缺陷，並決定負責組織團隊的郵件摘要。這給了我一個很好的機會去諮詢他們對一個話題的解釋，可是實際上更關鍵的是當有人提出問題的時候我能意識到那是否是須要修復的 bug 。

—–@brettcannon

你喜歡策劃活動嗎?

組織關於項目的研討會或者線下聚會，就像 @fzamperin
組織項目會議（若是他們有的話）
幫助社區成員找到合適的會議主題並提交一份發言稿。

你喜歡設計嗎？

重構項目的佈局以增長其易用性
組織用戶使用調查來重構項目的導航或者菜單
把樣式指南放在一塊兒以此來幫助項目有一致的視覺設計
設計 t-shirt 或者新的logo，就像是hapijs的貢獻者們作的同樣

你喜歡寫做嗎？

編寫或者改善項目的文檔
建立一個文件夾展現項目怎樣使用的例子
給項目編寫教程，就像pypa的貢獻者們作的同樣
爲項目的文檔作翻譯

認真的說，[文檔]真的是重要得一逼。目前Babel的文檔已經很棒了，這也是其殺手鐗的特性之一。固然，還有一些章節須要你們的完善，即便是隨便在哪兒增長一個段落都很感激。

你喜歡組織嗎？

鏈接重複的 issue，或者爲某個iuuse添加新的標籤來讓事情變得井井有理
檢查打開的 issue，就像@nzakas給eslint作的那樣
問一個明確的問題推薦討論

你喜歡寫代碼嗎？

找一個 issue 去解決。就像@dianjin給Leaflet作的那樣
詢問項目全部者你是否能夠幫忙寫一個新的功能
使配置項目的過程自動化
改善工具鏈和測試

你喜歡幫助別人嗎?

在諸如 Stack Overflow或者reddit上回答關於項目的問題（這裏有一個關於Postgres例子）
在打開的 issue 中回答人們的問題
幫助調整討論板塊或者對話渠道

你喜歡幫助改善別人的代碼嗎?

審查別人提交的代碼
寫一個關於項目如何使用的教程
幫助其餘的貢獻者，就像在Rust項目上@ereichert爲@bronzdoc作的那樣

你不必定只能給軟件項目作貢獻！

雖然開源通常指的是軟件項目，實際上你能夠在任何項目上進行協做。有不少書籍，經驗貼，列表，課程都是開源項目。好比：

@sindresorhus策劃了 awesome 系列的列表
@h5bp持有一份關於前端常見面試問題的列表
@stuartlynn 和 @nicole-a-tesla製做了一份關於[海雀的有趣現象集錦]

即便你不是你個軟件工程師，給一個文檔性質的項目作貢獻也會讓你邁進開源世界的大門。在沒有代碼的項目上作事一般沒那麼嚇人（相比與有代碼的項目來講）,並且這個寫做的過程會讓你積累更多自信和經驗。

投身於一個新項目

若是你打開一個項目的 issue tracker 。裏面的東西可能讓你以爲不解，不僅是你有這樣的感受。這些工具須要不少的隱性知識，可是人們會幫助你搞清楚，你也能夠問他們問題。 —-@shaunagm 「How to Contribute to Open Source」

對於那種不只僅是修復一個手誤的工做，給開源項目作貢獻就像是在一個聚會上走近一羣陌生人同樣。當他們正在熱火朝天的討論金魚的時候，你插進去開始講駱駝,他們會像你投來異樣的眼光。

在你帶着你的看法盲目的加入討論以前，首先研究一下他們到底在討論什麼。這樣會增長你的觀點被注意到和聽取的機會。

分析一個開源項目

每個開源社區都不同。

在一個項目上花費數年的事件會讓你對這個項目瞭如指掌。可是當你遷移到另一個項目中時，你會發現他們的詞彙，規範和討論的風格徹底不同。

話雖如此，不少開源項目仍是遵循一個類似的組織結構。理解不一樣社區的角色和整體的進程會幫助你很快的融入一個新的項目。

一個經典的開源項目會有這樣幾類人：

做者： 建立該項目的人或者組織
全部者： 對該組織或者倉庫有行政權的人（一般和原始的做者不是一我的）
** 維護者：** 那些負責宣傳項目，管理項目組織的貢獻者（他們也多是做者或者全部者）
貢獻者： 每一個給項目作出或多或少貢獻的人
社區成員： 使用項目的人。他們可能在關於項目方向上的討論中積極發表本身的觀點

更大型的項目可能有針對不一樣工做的子社區或者工做組，好比工具鏈，工做分配，打造社區的溫馨度和事件管理。查看項目網站上的「團隊」頁面，或者存放管理文檔的倉庫尋找這些信息。

一個項目也會有他本身的文檔，這些文件放在項倉庫目的一級目錄。

LISENCE：因爲開源項目的定義，每一個開源項目都要有一個開源協議。若是一個項目沒有一個開源協議，那麼他就不是開源項目。
README：README文件是給社區的新成員的使用手冊。它解釋了爲何這個項目是有用的和怎麼開始使用這個項目。
CONTRIBUTING：READMEj文件是幫助人們使用項目的，而CONTRIBUTING文檔是幫助人們對項目作貢獻。可是不是每一個項目都有CONTRIBUTING文件，那麼有這個文件就標誌着這是一個開放的項目。
CODE_OF_CONDUCT：行動守則制定了參與者行爲的基本規則，幫組促進了社區的友好，開放的氛圍。可是不是全部項目都有 CODE_OF_CONDUCT 文件，若是有的話那就標誌着這是一個開放的項目。
Other documentation：還可能有其餘的文檔，好比教程，預覽，或者管理政策，尤爲是在大型項目中會出現。

最後，開源項目使用下面這些工具來管理討論。在你閱讀本文的過程當中，你會對開源社區思考和工做的方式有一個整體的映像。

Issue tracker：人們用來討論和項目相關的問題的地方
Pull requests: 人們用來討論和審查正在進行中的修改。
Discussion forums or mailing lists（論壇或者郵件列表）：有些項目會用不一樣的頻道對應不一樣的討論主題（好比說，「我怎樣才能…」或者「大家對於…的見解是」，而不是 bug 報告或者功能請求。另一些項目直接用 Issue tracker 進行全部話題的討論。
Synchronous chat channel（匿名的聊天頻道）：有些項目用聊天頻道（好比Slack或者IRC)來進行隨意的討論，合做，或者快速的修改。