如何从0开始开源项目参与_如何开始一个开源项目

如何从0开始开源项目参与

by Dmitriy Strukov

德米特里·斯特鲁科夫(Dmitriy Strukov)

如何开始一个开源项目 (How to start an Open Source project)

My name is Dima and I’m Ruby developer. Today I want to share my experience creating an open source solution. I will talk about what steps the project should take, how to choose the right functionality for the first release, and what mistakes I faced personally when creating my open source project.

我叫Dima，我是Ruby开发人员。 今天，我想分享我创建开源解决方案的经验。 我将讨论项目应采取的步骤，如何为第一个发行版选择正确的功能以及在创建开源项目时遇到的个人错误。

Half a year ago, I got the idea that it would be good to create an open source project. Instead of test tasks for the interview, it would be enough for me to send a link to the repository. The prospect of helping colleagues with the solution to their everyday problems inspired me.

半年前，我想到创建一个开源项目会很好。 无需进行面试的测试任务，将链接发送到存储库就足够了。 帮助同事解决日常问题的前景启发了我。

I’ve always disliked gems for creating administration panels. Any extra movement needs to redefine the class, and for change fields you need to make changes to the files. After thinking and conversing with colleagues, I decided to create a new library which would be flexible and would not require dashboards or configuration files.

我一直不喜欢创建管理面板的宝石。 任何额外的动作都需要重新定义类，对于更改字段，您需要对文件进行更改。 经过与同事的思考和交谈，我决定创建一个新的库，该库将很灵活并且不需要仪表板或配置文件。

确定目标 (Determine the goals)

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

每个开源项目都会解决一个特定的问题。 与同事交谈，聊天，论坛并分享您的想法。 所有这些都可以帮助您从头开始理解重要的事情，例如已经存在的解决方案，以及聆听批评。 与已经拥有开源项目的人交谈。 他们可以为您提供非常有价值的建议，因此不要害怕提出问题并采取主动。

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

我在此阶段获得的一个重要建议是，首先要注意项目文档。 您可以有一个非常好的项目，但是没有人会花时间来了解它的工作原理。

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.

最重要的方面是没有动力，没有进一步的步骤是不可能的。 该项目的想法应首先激发您的灵感。 人们通常会习惯使用的工具，并陷入舒适的境地，因此外部意见可能会含糊不清。

规划 (Planning)

The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

特定任务管理器的选择取决于品味。 它应该对项目的任务和阶段有清晰的了解。

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

将任务划分为子任务。 理想情况下，如果一项任务花费的时间不超过3-4个小时，则享受小任务的执行很重要。 这将有助于避免倦怠和失去动力。

I use pivotal tracker. The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.

我使用枢轴跟踪器 。 主要优势是开放源代码项目的免费版本，您可以在其中按类型(功能，错误，杂项，发布)对任务进行排序，并将其分组为发布和确定的期限。

文献资料 (Documentation)

Every open source project should contain these things:

每个开源项目都应包含以下内容：

• README
  自述文件
• Open Source license
  开源许可证
• Contributing guidelines
  贡献准则
• Changelog
  变更日志

The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template.

README文件不仅说明了如何使用您的项目，还说明了项目的目的。 如果您不知道如何正确编写README文件，则可以查看其他已知的开源项目或使用模板 。

The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service.

该许可证保证其他人可以使用，复制和修改项目的源代码。 您需要将此文件与您的开源项目一起添加到每个存储库中。 MIT和Apache 2.0 GPLv3是开放源代码项目中最受欢迎的许可证。 如果不确定选择什么，可以使用此便捷服务 。

The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.

CONTRIBUTING文件将帮助其他开发人员对该项目做出贡献。 在项目的第一步，不必密切关注此文件。 您可以使用另一个项目中已经准备好的模板。

Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.

变更日志包含受支持的按时间顺序排列的每个版本的重要变更列表。 与CONTRIBUTING文件一样，我不建议在早期特别注意这一点。

版本控制 (Versioning)

To track important changes for users and contributors, there is a semantic version. The version number contains numbers and adheres to the following pattern X.Y.Z.

为了跟踪用户和贡献者的重要变化，有一个语义版本 。 版本号包含数字，并遵循以下模式XYZ

• X major release
  X主要版本
• Y minor release
  Y次要发布
• Z patch release
  Z补丁发布

持续集成/持续交付 (Continuous integration / Continuous delivery)

To automatically run tests and build, I use Travis CI. It’s also a good idea to add badges to display the successful assembly of the build in the wizard, the test coverage (Codecov), and the documentation (Inch CI).

为了自动运行测试和构建，我使用Travis CI 。 添加标记以在向导中显示构建的成功组装，测试覆盖率( Codecov )和文档( Inch CI )也是一个好主意。

After each new commit or merge in the master, I automatically have a deploy on Heroku (very convenient integration with GitHub). All tools are absolutely free for an open source project.

在主服务器中的每个新提交或合并之后，我会自动在Heroku上进行部署(非常方便地与GitHub集成)。 所有工具对于一个开源项目都是完全免费的。

我的错 (My mistakes)

To analyze the initial stage, I had an idea, but there was no clear plan. I decided that I wanted to do this without having a clear idea of how much time it would take or a specific representation of the functions that would be in the first version of the library. I had just a lot of desire and lack of a clear plan.

为了分析初始阶段，我有一个主意，但是没有明确的计划。 我决定在不明确需要多少时间或没有明确表示该库的第一个版本中的功能的情况下进行此操作。 我只是有很多愿望，却缺乏明确的计划。

Also, after reading the history of other projects (not only open source), I noticed that at an early stage, some plans are too optimistic. They need a reassessment of their strengths and capabilities. But it’s not easy to find time each day to write a new feature in the project. Most of the tasks eventually had to be weeded out, leaving the necessary minimum for MVP.

另外，在阅读了其他项目(不仅是开源项目)的历史之后，我注意到在早期阶段，有些计划过于乐观。 他们需要重新评估自己的优势和能力。 但是每天找时间在项目中编写新功能并不容易。 最终，大多数任务都必须清除掉，剩下MVP所需的最低要求。

At the moment my simple-admin project is in the alpha version. Further plans include creating a separate version of the library for Hanami.

目前，我的simple-admin项目处于alpha版本。 进一步的计划包括为Hanami创建该库的单独版本。

翻译自: https://www.freecodecamp.org/news/how-to-start-an-open-source-project-in-new-years-945bad8800d7/

如何从0开始开源项目参与