开源贡献 计算

Are you a new developer? Or maybe even just an old-timer who has been in a company for ten years, working on an in-house project, and now you’re thinking, “Hey, I’ve been in my box a long time. What’s new out there?” I have been like that before, and I had my own fears to conquer during those times.

您是新开发者吗？ 也许只是一个在公司工作了十年的老朋友，从事内部项目，现在您在想：“ 嘿，我已经待了很长时间了。 那里有什么新东西？” 我以前就是这样，在那段时期我有自己的恐惧要征服。

When I graduated, I had the general direction of my career in mind: web development, games, or both. I loved the Internet and I had the knowledge to go to town on it. At that point in time, naïve me felt invincible knowing HTML/CSS. I also knew some Flash and PHP, so I thought I was a very versatile developer (yes, we had our proud moments).

毕业后，我想到了职业发展的总体方向：网站开发，游戏或两者兼而有之。 我喜欢互联网，而且我有知识可以上网。 在那个时间点上，我天真地了解HTML / CSS。 我也知道一些Flash和PHP，所以我认为我是一个非常多才多艺的开发人员(是的，我们度过了自豪的时光)。

Long story short, I got into some web developer and game dev roles. At some point in time, I was introduced by my good friend Topher to the world of Ruby.

长话短说，我进入了一些Web开发人员和游戏开发人员的角色。 在某个时候，我的好朋友Topher向我介绍了Ruby的世界。

I was new to everything it offered:

我对它所提供的一切都是陌生的：

• Git (my form of version control with my Flash work was like FINAL-FINAL-V22.zip)Git(我使用Flash进行版本控制的形式就像FINAL-FINAL-V22.zip)
• Command line: sure, had some experience with PHP, but on a Windows machine, it wasn’t much命令行：当然，有一定PHP经验，但是在Windows机器上并没有太多
• Unix的Unix

Back then, I had no clue what open source was. I knew PHP was open source, and that it basically meant the source code was there for everyone to see. That was that.

那时，我不知道什么是开源。 我知道PHP是开源的，它的基本含义是所有人都可以看到源代码。 就是那样

输入Github (Enter Github)

In my opinion, Github set the precedent for the boom in open source. Ruby on rails was fairly new back then as well, and when Github was made using Rails, it was the start of my open source journey.

我认为， Github为开源热潮开创了先例。 当时的Ruby on Rails也是相当新的东西，当使用Rails制作Github时，这就是我的开源之旅的开始。

It wasn’t until a year and a half later when I created my “first” open source project. It was actually just a fork of Bob Craven’s work in which I modified some parts for another project.

直到一年半之后，我才创建了我的“第一个”开源项目 。 实际上，这只是Bob Craven的工作的一部分，我在其中修改了另一个项目的某些部分。

Another year later, I created my first issue and pull request. Yes, it took me a year! After this, though, I felt more confident and with encouragement from my boss, who was an open source advocate as well, I contributed more and more to open source.

一年后，我创建了我的第一个期并提出要求 。 是的，花了我一年！ 但是，在此之后，我感到更加自信，并且在老板(同时也是开源倡导者)的鼓励下，我为开源做出了越来越多的贡献。

那么我如何克服这种恐惧呢？ (So how do I get over that fear?)

First and foremost, ask yourself why you’re afraid of contributing. It’s the first step in overcoming a fear (at least for me!).

首先，问问自己为什么害怕贡献。 这是克服恐惧的第一步(至少对我而言！)。

Here were my own fears in addition to the most common ones I have heard about (that have been to me by students, colleagues, and so on) which may or may not apply to you:

除了我所听到的最常见的恐惧(学生，同事等对我的恐惧)之外，还有一些我自己的恐惧，这些恐惧可能对您也可能不起作用：

• What if my contribution is not accepted?如果我的捐款不被接受怎么办？
• What if I write crap code that nobody likes?如果我编写没人喜欢的废话代码怎么办？
• Will people judge me for the code I write?人们会根据我编写的代码来判断我吗？
• I can’t understand any of their code! :(我不明白他们的任何代码！ :(
• I don’t know how to code / I’m just a newbie.我不知道如何编码/我只是一个新手。
• I don’t know where to start!我不知道从哪里开始！

After listing these fears down, address them one by one or at least try to find solutions to how you can address them. As such, I can list some solutions to these and hopefully help some of you to get over that hump and start contributing.

在消除这些恐惧之后，一一解决，或者至少尝试找到解决方法。 因此，我可以列出一些解决方案，希望能帮助你们中的一些人克服困难并开始做出贡献。

如果我的捐款不被接受怎么办？ (What if my contribution is not accepted?)

To be honest, this is not that huge of a fear for me, but more of an inconvenience. There’s that little part of me that dies when my work is rejected (who doesn’t?), but that’s just the way it is. We just have to learn to accept that sometimes. A pull request may not be accepted because of code quality, duplication, and so on. And it’s OK. I can’t stress that enough.

坦白说，这对我来说并不是太大的恐惧，而是给您带来的不便。 当我的工作被拒绝(谁没有被拒绝)时，我只有一小部分人死亡，但这就是事实。 有时候我们只需要学会接受。 由于代码质量，重复等原因，可能不接受请求请求。 没关系 。 我不能太强调。

In my early years of contributing, I had a few rejections and it was a bit disheartening. Take note though, some actually don’t reject you outright since with some projects, maintainers are overwhelmed by pull requests or some issues are already solved but not yet released.

在我早期的贡献中，我遭到了一些拒绝 ，这令人沮丧。 但是请注意， 实际上有些人并不会直接拒绝您，因为在某些项目中， 维护人员会被请求请求淹没，或者某些问题已经解决但尚未发布 。

My advice is to just move along and look for other options. You can’t dwell on a pull request forever! Try to get something from it. In the rejection I had, I learned to do fewer commits paired with smaller pull requests, and not one epic feature in one go.

我的建议是继续前进并寻找其他选择。 您不能永远停留在请求请求上！ 尝试从中得到一些东西。 在我的拒绝中，我学会了更少的提交和更小的拉取请求，一次也不做任何史诗功能。

如果我编写没人喜欢的代码怎么办？ (What if I write code that nobody likes?)

I don’t think anyone dislikes code, especially something that was supposed to help a project. Sure, there are some projects that will require a higher quality of code than others, but in the end, contributions are what powers them — so hopefully no one will call your code ?.

我认为没有人不喜欢代码，尤其是那些本来可以帮助项目的代码。 当然，有些项目需要比其他项目更高的代码质量，但是最终，贡献才是推动它们发展的动力-因此希望没人能称呼您的代码？

In most open source projects, people will comment and offer constructive advice on how to improve your contribution. Learn from them and follow their advice. Refactor. Most importantly, ask the maintainers how you can fix it and/or point you in the right direction. You’d be surprised how easily they will provide you with the tools that you need!

在大多数开源项目中，人们将就如何提高您的贡献发表评论并提供建设性建议。 向他们学习并遵循他们的建议。 重构。 最重要的是，询问维护人员如何修复它和/或为您指明正确的方向。 您会惊讶于它们为您提供所需工具的便捷程度！

人们会根据我编写的代码来判断我吗？ (Will people judge me for the code I write?)

In my experience, most people don’t judge you for your code (at least the hundreds of developers I have encountered have not). Now, the thing to keep in mind is that whenever you write code you are not sure about, ask for someone else’s opinion, or ask a more senior developer to review it for you. If you don’t know anyone that fits the bill, then let the maintainers know in your pull request description that you probably have some not-so-good code and ask for their opinion.

根据我的经验，大多数人不会根据您的代码来判断您(至少我遇到的数百名开发人员没有)。 现在，要记住的事情是，每当您编写代码时，您都不会确定，征询别人的意见，或者请更高级的开发人员为您审阅代码。 如果您不认识合适的人，请在维护请求的描述中告知维护者您可能有一些不太好的代码，并征求他们的意见。

I think it’s just best to be open on these kinds of things, and if they have the time, they will surely let you know and help you out. The best way to get a good response though is to not just ask “How do I make this better?” Not everyone has the time to help everyone else out, so it would save a lot of time for you (and for the maintainer!), if you first research how to make your code better and then ask for help. More like, “Hi, I’m still new here, but here’s what I have done, and some links to sources on why I did it this way. I think it is still not good enough, and was wondering if you have any opinions or if you could point me in the right direction.” That sort of thing.

我认为最好是对这些事情保持开放，如果有时间的话，他们一定会告诉您并帮助您。 不过，获得良好回应的最好方法是不只是问“如何使它变得更好？” 并非每个人都有时间帮助其他人，因此，如果您首先研究如何使代码变得更好， 然后寻求帮助，则可以为您(以及维护者！)节省大量时间。 更像是，“嗨，我在这里还很新，但这是我所做的，还有一些有关我为什么这样做的消息来源的链接。 我认为这还不够好，并且想知道您是否有任何意见或是否可以向我指出正确的方向。” 诸如此类的事情。

我不懂他们的任何代码！ (I don’t understand any of their code!)

This still bugs me sometimes. This is mostly true on many huge open source projects like Rails, React, and others like that. Usually, the only way to understand is to encounter a problem / bug and reproduce it on your end. All I can really say is that you don’t have to understand everything, but at least know how things work as a bare minimum.

有时候，这仍然困扰着我。 在许多大型开源项目中，例如Rails，React和其他类似项目，这都是正确的。 通常，了解的唯一方法是遇到问题/错误并最终复制它。 我真正能说的是，您不必了解所有内容 ，但至少要了解事情的最低限度。

I once had a student while I was mentoring who asked me about this. He wanted to really push himself and I suggested that one challenge (that I myself haven’t finished!) is to create a pull request to Rails or whatever project he was fond of. A week later, he was beaming when he mentioned he got his first pull request merged. It was a pull request to the Japanese version of the Rails guide. I was a very proud mentor that day.

在指导期间，我曾经有一个学生问这个问题。 他想真正推动自己，我建议一个挑战(我自己还没有完成！)是向Rails或他喜欢的任何项目创建请求请求。 一周后，当他提到他合并了他的第一个拉取请求时，他很高兴。 这是对日语版Rails指南的要求。 那天我是一个非常自豪的导师。

He didn’t understand Rails fully yet, but he REALLY wanted to contribute to it. So instead of looking at Rails itself, he helped out in another way by fixing translations so non-English speakers / readers could understand it better.

他还没有完全了解Rails，但他确实想为此做出贡献。 因此，他没有看Rails本身，而是通过修复翻译以另一种方式提供了帮助，以便说非英语的人/读者可以更好地理解它。

This brings me to another point which actually addresses another fear…

这把我带到了另一个可以解决另一个恐惧的地方……

我不知道如何编码/我只是新手 (I don’t know how to code / I am just a newbie)

We all have to start somewhere. All the experts, maintainers, and famous developers you know all started as a newbie. The key thing here is that they managed to improve themselves and didn’t let being a new developer block them from doing something great.

我们都必须从某个地方开始。 您认识的所有专家，维护人员和著名开发人员都是从新手开始的。 这里的关键是他们设法提高自己，并且不让自己成为一名新开发人员来阻止他们做大事。

Now, I know a LOT of people who don’t even have a Computer Science background, who know a lot more than I do (and I have a CS degree!). Not knowing how to code should not be a source of fear, since you can contribute without coding.

现在，我认识了很多甚至没有计算机科学背景的人，他们比我了解得多(我拥有CS学位！)。 不知道如何编码不应引起恐惧，因为您无需编码即可做出贡献。

Bear in mind, contributing does not only mean making pull requests! It can be participating in a discussion about a feature, pointing out errors, or even filing bugs (be sure to follow their contributing procedures!)

请记住， 贡献不仅意味着提出请求 ！ 它可以参与有关功能的讨论，指出错误，甚至可以提交错误(请务必 遵循 其 参与 程序 ！)

Most of the time, a project will need translators or proof readers. If you fancy doing those tasks, go look for a project you like and support them. I am an avid fan of Elixir, and while I haven’t written production Elixir code, I volunteered to help maintain the style guide. Of course, I asked the maintainer first, but it was also my way of training myself to Elixir syntax and project management of sorts. I didn’t have to be an Elixir expert, I mostly managed the issues and double checked the submitted pull requests.

大多数时候，一个项目将需要翻译或校对者。 如果您愿意执行这些任务，请去寻找您喜欢的项目并提供支持。 我是Elixir的狂热爱好者，虽然我还没有编写生产Elixir的代码，但我自愿帮助维护样式指南 。 当然，我首先问维护者，但这也是我训练自己掌握Elixir语法和各种项目管理的方式。 我不必成为Elixir专家，我主要负责管理问题并仔细检查了提交的请求请求。

大！ 我可以从哪里开始？ (Great! Where can I start?!)

Again, Github is a good place to start. If you have a project you support, try to look there first. Otherwise, if you feel like you can conquer anything, look at the trending repositories in Github or even Explore Gitlab.

同样，Github是一个不错的起点。 如果您有一个支持的项目，请尝试先看看那里。 否则，如果您觉得自己可以征服一切，请查看Github中甚至是探索Gitlab中的热门存储库 。

Now go forth and spread the open source love!

现在继续传播开源之爱！

Update: I have also made an article about making your first pull request (and getting it merged) as a supplement to this. Check it out here.

更新：我还写了一篇有关提出您的第一个拉取请求(并将其合并)的文章，作为对此的补充。 在这里查看 。

翻译自: https://www.freecodecamp.org/news/how-to-get-over-your-fear-of-contributing-to-open-source-6160e4cdf0d3/

开源贡献 计算