開源項目貢獻者

by Dhanraj Acharya

通過Dhanraj Acharya

我如何從一名貢獻者轉變為一個開源項目維護者 (How I went from being a contributor to an Open Source project maintainer)

I was a lone software developer. When I was in college, I attended the KDE conference. It was my first encounter with the open source world. At the conference, I thought the presenters and the people raising hands were very smart. I knew there was free software available, created by the community for the community. But the developers that build it were foreign to me.

我是一個孤獨的軟件開發人員。 在上大學時，我參加了KDE會議。 這是我第一次接觸開源世界。 在會議上，我認為主持人和舉手的人都很聰明。 我知道有可用的免費軟件，由社區為社區創建。 但是構建它的開發人員對我來說是陌生的。

I thought really cool, intelligent people developed this software. I thought you had to to be really smart and privileged to join them.

我以為真的很酷，聰明的人開發了這個軟件。 我認為您必須非常聰明并且有特權加入他們。

I tried to participate in Google Summer of Code (GSOC) two times during college, but wasn’t successful. Then after graduation, during my job, I used lots of open source projects. I even used them when freelancing. I heavily relied on community-developed tools and tech. I was really fascinated with people’s stories on how they started contributing to open source, and how they got their amazing remote jobs!

我在大學期間曾嘗試過兩次參加Google的代碼暑假( GSOC )，但沒有成功。 畢業后，在我的工作中，我使用了許多開源項目。 我什至在自由職業時也使用它們。 我嚴重依賴社區開發的工具和技術。 人們對他們如何開始為開源做出貢獻以及如何獲得出色的遠程工作的故事深深著迷。

Now after procrastinating for another two months and not being able to land a remote job, I decided to do it once and for all and contribute myself.

現在，在拖延了兩個月又無法找到遠程工作之后，我決定一勞永逸地做出自己的貢獻。

I started uploading my code to the GitHub — whenever wrote any new code. I created an open source NPM module along with some other demo projects and uploaded them. But this wasn’t the gist of open source. I wasn’t actually contributing to other repos or working with other developers to create software. I was still working in isolation.

每當編寫任何新代碼時，我就開始將代碼上傳到GitHub 。 我創建了一個開源NPM模塊以及其他一些演示項目，并上傳了它們。 但這不是開源的要旨。 我實際上并沒有為其他存儲庫做出任何貢獻，也沒有與其他開發人員一起創建軟件。 我仍在孤立地工作。

啤酒節！ (Hacktoberfest!)

Then it came: I stumbled upon Hacktoberfest. They (DigitalOcean, GitHub, and Twilio) were giving away a free t-shirt if you submitted 5 Pull Requests to an open source project on GitHub in October. Even if your PR was not merged, still it counted towards your progress. And this time, they had a ton of t-shirts, so, it was easy to get one. This was the final push I needed — apparently, a free t-shirt gives you an amazing boost!.

然后它來了：我偶然發現了Hacktoberfest 。 如果您在10月份向GitHub上的一個開源項目提交了5個Pull Requests，他們(DigitalOcean，GitHub和Twilio)將免費贈送一件T恤 。 即使您的PR沒有合并，它也會計入您的進度。 這次，他們有大量的T恤衫，因此一件一件很容易。 這是我需要的最后一個推動力-顯然，免費的T恤給您帶來了驚人的提升！

So thus I started my journey in the OPEN SOURCE WORLD.

因此，我開始了“開源世界”的旅程。

追蹤問題 (Tracking down the issues)

I searched for open source projects to tackle on GitHub. I wanted some easy tasks to quickly get familiar with the PR process. So I looked for issues which did not require me to jump into the whole source code.

我搜索了要在GitHub上解決的開源項目。 我想要一些簡單的任務來快速熟悉PR過程。 因此，我尋找的問題不需要我跳入整個源代碼。

There were many developers who started projects for Hacktoberfest and newcomers. It was easy to submit PR in these repos, so I submitted three PRs. I submitted my other two PRs to other people’s personal projects. There were many other repos where you just had to add your name to the file and submit the PR. But I decided that this was not productive and was not the spirit of open source.

有許多開發人員為Hacktoberfest和新手啟動了項目。 在這些存儲庫中提交PR很容易，因此我提交了三個PR。 我將另外兩個PR提交給其他人的個人項目。 還有許多其他存儲庫，您只需要將名稱添加到文件中并提交PR。 但是我認為這沒有效果，也不是開源精神。

Then I came across this amazing developer. She had created a static blog in Vue.js and had many issues listed. When I saw all of the issues, I found out that basically, she was making a personal blog and getting people to contribute by raising issues and labeling them with appropriate tags. I was like ?.

然后我遇到了這個了不起的開發人員。 她在Vue.js中創建了一個靜態博客，并列出了許多問題。 當我看到所有問題時，我發現基本上是她在制作個人博客，并通過引發問題并用適當的標簽標記他們來促使人們做出貢獻。 我當時喜歡嗎？

Then I realized that the idea was great and I was like,

然后我意識到這個主意很棒，就像

I was impressed with her talent! She was building her static blog, and at the same time it was also benefiting other developers. First-timers were learning to work in the open source and getting a free t-shirt. She was getting her blog through a group effort!

她的才華讓我印象深刻！ 她正在建立自己的靜態博客，與此同時，它也使其他開發人員受益。 初學者正在學習在開源中工作并獲得免費的T恤。 她是通過集體努力獲得博客的！

Discovering her blog is what motivated me to create the Good Food Guide.

發現她的博客是促使我創建《美食指南》的動力。

美食指南的興起 (The rise of the Good food guide)

I had already decided what to do once I had finished submitting my PRs. So after two days of work and submitting PRs, it was time for a new beginning. I was inspired by all other developers who had created a repo to support Hacktoberfest. They all were creating a welcoming environment to encourage newcomers to submit productive PRs. I also wanted to give my contribution towards this movement and decided to create my own project repo.

完成提交PR后，我已經決定要做什么。 因此，經過兩天的工作并提交了PR，是時候重新開始了。 所有其他開發人員都創建了一個倉庫來支持Hacktoberfest，這給我帶來了啟發。 他們都在營造一個歡迎環境，以鼓勵新移民提交富有成效的PR。 我也想為此運動做出自己的貢獻，并決定創建自己的項目倉庫。

I too want to become an entrepreneur, and I have a list containing multiple ideas. But I did not want to put too much time into deciding which project to start. I looked through all the ideas and picked the one I thought was easy to understand and easy to implement.

我也想成為一名企業家，并且我有一個包含多個想法的清單。 但是我不想花太多時間來決定啟動哪個項目。 我仔細研究了所有想法，然后選擇了我認為容易理解和易于實施的想法。

I chose to build the Good Food Guide. My sister and I used to Google about which foods to eat to cure a particular disease. I thought, what if there’s already a site where you can just go and search for your symptoms or disease and it’ll tell you about the foods to eat? It should be available in all languages so multiple people can use it easily.

我選擇制作《美食指南》。 我姐姐和我曾經在Google上搜索過要吃哪種食物才能治愈特定疾病。 我想，如果已經有一個站點可以搜索癥狀或疾病，并且會告訴您要吃的食物，該怎么辦？ 它應該以所有語言提供，以便多個人可以輕松使用它。

So I created a basic UI which conveyed the motivation and use of the website. I wanted to quickly upload it, so I decided to have all the data in a static file only. I wanted to choose a technology which was easy to learn and widely used. This would allow new developers to learn or existing developers to practice. So I ended up using React.

因此，我創建了一個基本的UI，傳達了網站的動機和使用方式。 我想快速上傳它，所以我決定將所有數據僅保存在靜態文件中。 我想選擇一種易于學習和廣泛使用的技術。 這將允許新的開發人員學習或現有的開發人員進行練習。 所以我最終使用了React。

On top of it, I decided to use NextJs to leverage many of its features. It is also easy to use if you already know React. I uploaded the whole project on GitHub and the journey began. But this wasn’t enough to attract the developers.

最重要的是，我決定使用NextJs來利用其許多功能。 如果您已經知道React，它也很容易使用。 我將整個項目上傳到GitHub ，然后旅程開始了。 但這還不足以吸引開發人員。

維護者的崛起 (The rise of the maintainer)

After committing the initial code, I then produced proper documentation. I created issues with the appropriate labels. I created the issue just like we create tasks in an agile sprint. Moreover, I divided the tasks into sub-tasks and listed them with full details.

提交了初始代碼后，我便制作了適當的文檔。 我使用適當的標簽創建了問題。 我創建了問題，就像我們在敏捷的sprint中創建任務一樣。 此外，我將任務劃分為子任務，并列出了全部細節。

When I was looking for issues to contribute to, I looked for issues with a detailed problem and directions for the solution. So I tried to include the information I initially looked for in the issues.

當我尋找有助于解決問題的問題時，我尋找的問題包括詳細的問題和解決方案的指導。 因此，我嘗試將最初尋找的信息包括在這些問題中。

This worked like a charm, and it was exactly what was needed to get the first timer contributors aboard. Most popular projects are useful to contribute to. The lack of information in issues works as a demotivation for them. Due to this, most of them don’t work on actual issues after compiling the code.

這就像一種魅力，而這正是使第一個計時器貢獻者獲得所需的條件。 大多數最受歡迎的項目都有助于做出貢獻。 問題中缺乏信息對他們不利。 因此，大多數代碼在編譯后都無法解決實際問題。

示例問題 (Example issue)

One more thing which I did was publish the master branch with Netlify. Netlify has a great integration app with GitHub. So if any PR is merged then the contributor can see the change go LIVE almost instantly.

我要做的另一件事是與Netlify發布master分支。 Netlify具有與GitHub的出色集成應用程序。 因此，如果任何PR合并，則貢獻者幾乎可以立即看到更改生效。

The result? I got 3 PRs and 4 requests to work in just 2 hours (told you, the power of free T-shirt is very strong ?).

結果？ 我在短短2個小時內獲得了3個PR和4個請求(告訴您，免費T恤的功能非常強大嗎？)。

I successfully went from being a contributor to a project maintainer!

我從成為項目維護者的貢獻者成功地轉變了！

了解硬幣的另一面 (Understanding the other side of the coin)

The repo was becoming more popular. People were raising issues for suggestions, submitting PRs, and commenting on issues. My repo was getting attention and it was just amazing.

回購正變得越來越受歡迎。 人們在提出問題以尋求建議，提交PR以及評論問題。 我的回購引起了人們的注意，這真是太神奇了。

I was getting notifications all day. Every hour I would get at least one notification from GitHub! I was juggling here and there. I was reviewing PRs, answering comments, merging PRs, raising more issues, and contributing.

我整天都收到通知。 每小時我都會收到至少一個來自GitHub的通知！ 我在這里和那里玩雜耍。 我正在審查PR，回答評論，合并PR，提出更多問題并做出貢獻。

One amazing feature that came handy by integrating Netlify was that it automatically sets CI (Continuous Integration) for your project. It performs various checks on the submitted PR, and also gives a test deployment where you can check the integration. I recommend using this feature in any projects you can!

集成Netlify時非常方便的一項令人驚奇的功能是，它會自動為您的項目設置CI(連續集成)。 它對提交的PR執行各種檢查，還提供了一個測試部署，您可以在其中檢查集成。 我建議您可以在任何項目中使用此功能！

As a result, people were learning and having fun! And also getting a Free T-shirt. I learned so much about GitHub and git. Pro tip: if you want to learn git fast then become an open source project maintainer. It gave me a new perspective and broadened my vision. So it was a win-win situation for all of us.

結果，人們在學習并獲得樂趣！ 并獲得免費的T恤。 我學到了很多關于GitHub和git的知識。 專家提示：如果您想快速學習git，請成為開源項目維護者。 它給了我一個新的視角，拓寬了我的視野。 因此，這對我們所有人都是雙贏的局面。

“Anything that can go wrong will go wrong.” — Murphy’s Law“任何可能出錯的地方都會出錯。” - 墨菲定律

For some time, I would check the PR details, skim through the code, look at the deployed integration and merge the PRs. Sometimes, due to many pending PRs, after merging the first PR, it would create a ripple effect and there would be conflicts in all other PRs. Now, this looked bad initially but it was a blessing in disguise. Due to this, I learned how to resolve conflicts in git. I resolved many conflicts. Github’s online editor for merging PRs proved very handy for small changes.

在一段時間內，我將檢查PR詳細信息，瀏覽一下代碼，查看已部署的集成并合并PR。 有時，由于有許多待處理的PR，在合并第一個PR之后，會產生連鎖React，所有其他PR都存在沖突。 現在，這最初看起來很糟，但這是變相的祝福。 因此，我學習了如何解決git中的沖突。 我解決了許多沖突。 Github的用于合并PR的在線編輯器對于微小的更改非常方便。

Although the PRs did not all have good code quality, I still merged most of them. Because as they were from the first time contributors, I did not want to discourage them from submitting more PRs. I know the feeling when you submit a PR and keep waiting for the maintainer to approve or comment on it. So to keep the spirit of the contributors up, I decided to merge the PR and then do the clean up myself (and I think this resulted in a positive feeling for contributors).

盡管PR并非都具有良好的代碼質量，但我仍然合并了大多數PR。 因為他們是來自首次捐助者，所以我不想阻止他們提交更多的PR。 我知道您提交PR并一直等待維護者批準或發表評論時的感覺。 因此，為了保持貢獻者的精神，我決定合并PR，然后自己清理(我認為這對貢獻者產生了積極的影響)。

As the number of PRs increased, I couldn’t give much time to contributing myself. Most of my allotted time would go to answering comments, emails, and merging and resolving PRs. After three days, I sat down to clean the code. It was a mess I only invited. I realized that I should have informed the contributors to follow at least some guidelines. The file names, function names, and project structure was all wrong. As the website was evolving, so were its problems.

隨著PR數量的增加，我不能花太多時間貢獻自己的力量。 我分配的大部分時間都用于回答評論，電子郵件以及合并和解決PR。 三天后，我坐下來清理代碼。 我只邀請了一個爛攤子。 我意識到我應該已經告知貢獻者至少要遵循一些準則。 文件名，函數名和項目結構都錯誤。 隨著網站的發展，其問題也在不斷發展。

I had to re-structure the whole codebase. It was a breaking change but it was much needed. If this continued, then the code would become non-maintainable after some time. This is when I realized why many companies emphasize their coding standards. I mean, I already knew the importance, but experiencing it first hand as a project maintainer was another thing! I could see why many popular open source projects were rigid about their coding standards.

我不得不重新構建整個代碼庫。 這是一個巨大的變化，但非常需要。 如果這種情況繼續下去，那么一段時間后代碼將變得不可維護。 這就是我意識到為什么許多公司都強調其編碼標準的時候。 我的意思是，我已經知道了重要性，但是作為項目維護者親身體驗是另一回事！ 我可以理解為什么許多流行的開源項目對他們的編碼標準都持嚴格態度。

I can also see how my thought process has evolved over the past 10–11 days. I was a na?ve contributor working on his own repository, but managed to become a project maintainer working with all other developers.

我還可以看到我的思維過程在過去10到11天內的發展情況。 我是一個天真的貢獻者，致力于他自己的存儲庫，但是設法成為了與所有其他開發人員一起工作的項目維護者。

GitHub統計 (GitHub Stats)

Here are the stars, forks and contributors in the past 11 days!

這是過去11天里的明星，叉子和貢獻者！

結果！ (The Result!)

A non-responsive website created in 10 minutes!

在10分鐘內創建了一個無響應的網站！

11天后， (After 11 days,)

You can also checkout the latest version of the website live at https://good-food-guide.now.sh.

您也可以在https://good-food-guide.now.sh上實時檢出網站的最新版本。

Each day the site is improving in a small or big way.

每天，網站都在以小或大的方式進行改進。

底線 (Bottom line)

This 11 day journey has been great for me. I’ve learned a lot. Now, I can see both sides of the coin.

這11天的旅程對我來說很棒。 我學到了很多東西。 現在，我可以看到硬幣的正反兩面。

I see the power of a team and what it can achieve. If a handful of people decide to work on a particular issue then they can solve anything. People need a welcoming environment and a little bit of reward to stay motivated.

我看到了團隊的力量以及它可以實現的目標。 如果少數人決定解決特定問題，那么他們可以解決任何問題。 人們需要一個熱情的環境和一點點的獎勵才能保持動力。

It can be difficult for new developers to start contributing. They look for issues to solve but it is not the only way to start contributing. The main idea is to have fun and build something collectively, to improve a piece of software. If you have used it and know something you can improve, then you can directly raise the issue, discuss with the maintainer, and submit a PR. I think this is one of the best ways to start.

新開發人員可能難以開始貢獻。 他們尋求解決的問題，但這不是開始貢獻的唯一途徑。 主要思想是娛樂并集體構建東西，以改進軟件。 如果您使用過它并且知道可以改進的地方，則可以直接提出問題，與維護者討論并提交PR。 我認為這是最好的開始方法之一。

It became clear to me how a project manager uses each individual’s strengths to accomplish a task that would’ve been difficult if done by a single person. This is the same situation in open source projects. The job of the maintainer is similar to the project manager. They have to maintain harmony between all developers and also listen to their thoughts.

對我來說，很清楚，項目經理是如何利用每個人的優勢來完成一項任務的，而如果由一個人來完成的話，這將是一件困難的事情。 在開源項目中也是如此。 維護者的工作類似于項目經理。 他們必須保持所有開發人員之間的和諧，并傾聽他們的想法。

I also realized that, before, I had this fear of a big codebase whenever I would think of joining a new open source project. I would compile the code, run it, and forget about it. Now that fear has gone and I think I can take the big step towards contributing to big projects. I hope to continue learning new things and become a good asset to the open source community.

我還意識到，以前，每當我想到加入一個新的開源項目時，我就擔心大型代碼庫。 我會編譯代碼，運行它，然后忘記它。 現在，這種恐懼已經消失了，我認為我可以朝著為大型項目做出貢獻邁出一大步。 我希望繼續學習新事物，并成為開源社區的寶貴財富。

Thank you for reading! And big thanks to Jennifer and Abbey from freeCodeCamp for reviewing. They helped me to prepare this article and make it worth your time.

感謝您的閱讀！ 非常感謝freeCodeCamp的Jennifer和Abbey的審閱。 他們幫助我編寫了這篇文章，并值得您花時間。

If you have any questions or suggestions, then leave them in the comments below.

如果您有任何問題或建議，請將其留在下面的評論中。

P.S. If you found this article helpful, clap! ??? It feels rewarding and gives me motivation to continue my writing.

附言：如果您發現本文很有幫助，請鼓掌！ ??? 感覺很有意義，并給了我繼續寫作的動力。

drex44/good-food-guideA guide to know which foods are good when you have certain disease! [Built in React/NextJs] - drex44/good-food-guidegithub.comGood Food GuideA guide to know which foods are good when you have certain disease! good-food-guide.now.sh

drex44 / good-food-guide 一個指南，當您患有某些疾病時，知道哪些食物是好的！ [內置于React / NextJs]-drex44 / good-food-guide github.com 良好食物指南 可以在您患某些疾病時知道哪些食物是有益的指南！ good-food-guide.now.sh

Edit:

編輯：

Updated the URL to the Live site to https://good-food-guide.now.sh.

將Live網站的URL更新為https://good-food-guide.now.sh 。

翻譯自: https://www.freecodecamp.org/news/how-i-went-from-being-a-contributor-to-an-open-source-project-maintainer-acd8a6b316f5/

開源項目貢獻者

總結

以上是生活随笔為你收集整理的开源项目贡献者_我如何从一名贡献者转变为一个开源项目维护者的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。