开源项目贡献者

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/

开源项目贡献者