How can a beginner participate in open source development?
Last time I published a post about the difficulties that developers face when trying to participate in open-source projects. I didn’t want to leave this problem without a description of a possible solution, so this time I translated an article by the famous open source activist Kent Dodds for you. In the article, the author shares several curious life hacking - I hope some readers will help them get more benefit / get more pleasure from participating in open-source projects.
After my recent post “For those who have it for the first time,” I received a lot of letters and messages asking “Which open project would you recommend to participate in?” In this post I will try to give an answer to this question, as well as to formulate a few recommendations regarding the first steps in the open source.
In the most general form, the answer is:
Personally, I am most satisfied with the work on projects that are important for me and my friends. The second key to success is to work on an ongoing basis. Regular work on the project will require an understanding of the features of using the software and the problems for which it was created - familiarity with the software from the user's point of view helps a lot.
What open libraries, frameworks, or tools do you most often use? Maybe you are working with Grunt, Gulp, Webpack or Browserify, and it seems to you that they could be improved or documented more precisely. Or, probably, you use the React library or the Angular module - they can also be slightly polished. You probably use any open source software - and improving it can help you in some way.
')
As soon as you have decided on a project in which you will participate, a second question arises: “And which side to take it for?”? Many projects have a CONTRIBUTING file. Looking into it, you will find instructions on how to participate in the project. If there is no separate file, the corresponding instructions can be in the README (usually located on the project’s home page). And if there is neither one nor the other, then you can send a pull request to add at least a skeleton CONTRIBUTING.md file to start negotiations on adding full-fledged instructions.
Get to know the project closer. Reading the documentation is good, but I like to know the project by code. My favorite way is to get into function calls through a debugger. For example, what happens if you contact angular.module?
Looking at the code, you will understand a lot about the principles of the library or framework. You can do the same with local tools using your favorite node debugger (or simply adding console.logs). Do not worry if something goes unclear. Do not give up - you can do it!
After you have learned the standards and procedural peculiarities of participation in the project and become acquainted with the principles of its work, it is time to determine the necessary changes to the project. I recommend to look at the existing problems and comment on those that seem interesting. After talking with the curators, you can find the optimal solution - and then create a pull request.
If you have your own ideas about fixing a bug or feature that you would like to implement, I highly recommend that you first discuss it with the curator (s) on GitHub issue . Maybe they will say that it lies outside the sphere of interests of the project or is already in development, or maybe they will tell you what kind of changes they would like to see in the program code. You will spend much less time, making sure that your pull request will be accepted before embarking on its design (just before making an offer to your wife, I first did everything to make the answer “yes”)
For the first pull request, just find any project with a suitable bug / feature and try to suggest your own improvements. Let the curators know that you are new and have nothing against their advice. If they are too busy, better look for another project. The first revision of the open source code is always difficult, so you may need the help and valuable guidance of more experienced participants. At this stage, the introduced code itself is not so important, it is important to learn how to work in an open-source project. Therefore, look for a project or person who has enough time and patience to direct you on the right path.
You may also be interested in a series of posts on how to participate in open-source projects on GitHub: https://blog.kentcdodds.com/introducing-how-to-contribute-to-open-source-be67917eb704.
Check out GitHub's issues for first-timers, good for beginners, good first bug (or good-first-bug), or help wanted. There are other resources for finding simple ways to participate in projects:
My first pull request was a request to correct a typo in the comment. He was very small and belonged to a project that I almost never used (I found a typo, hitting the code in the debugger). It was a good first contribution, although he didn’t have much influence on the project, but I didn’t really want to continue to participate in it. I have crossed the gap between the absence and the presence of the first contribution, and this is the main thing.
I really like to participate in open-source projects, and I strongly advise you to experience this experience. Yes, it is not easy to start, but after you take the first step, all subsequent ones will be given much easier. Of course, not always everything goes like clockwork. The open-source community has its quirks. Do not pay attention to them, just keep working. All must succeed! Good luck!
I would like to recommend another useful Kent article " Introducing: How to Contribute to Open Source ". It mentions his small course " How to Contribute to an Open Source Project on GitHub ".
After my recent post “For those who have it for the first time,” I received a lot of letters and messages asking “Which open project would you recommend to participate in?” In this post I will try to give an answer to this question, as well as to formulate a few recommendations regarding the first steps in the open source.
In the most general form, the answer is:
The best contribution you can make to the development of the software that you use regularly.
Personally, I am most satisfied with the work on projects that are important for me and my friends. The second key to success is to work on an ongoing basis. Regular work on the project will require an understanding of the features of using the software and the problems for which it was created - familiarity with the software from the user's point of view helps a lot.
What open libraries, frameworks, or tools do you most often use? Maybe you are working with Grunt, Gulp, Webpack or Browserify, and it seems to you that they could be improved or documented more precisely. Or, probably, you use the React library or the Angular module - they can also be slightly polished. You probably use any open source software - and improving it can help you in some way.
')
The first steps
As soon as you have decided on a project in which you will participate, a second question arises: “And which side to take it for?”? Many projects have a CONTRIBUTING file. Looking into it, you will find instructions on how to participate in the project. If there is no separate file, the corresponding instructions can be in the README (usually located on the project’s home page). And if there is neither one nor the other, then you can send a pull request to add at least a skeleton CONTRIBUTING.md file to start negotiations on adding full-fledged instructions.
Get to know the project closer. Reading the documentation is good, but I like to know the project by code. My favorite way is to get into function calls through a debugger. For example, what happens if you contact angular.module?
Looking at the code, you will understand a lot about the principles of the library or framework. You can do the same with local tools using your favorite node debugger (or simply adding console.logs). Do not worry if something goes unclear. Do not give up - you can do it!
After you have learned the standards and procedural peculiarities of participation in the project and become acquainted with the principles of its work, it is time to determine the necessary changes to the project. I recommend to look at the existing problems and comment on those that seem interesting. After talking with the curators, you can find the optimal solution - and then create a pull request.
If you have your own ideas about fixing a bug or feature that you would like to implement, I highly recommend that you first discuss it with the curator (s) on GitHub issue . Maybe they will say that it lies outside the sphere of interests of the project or is already in development, or maybe they will tell you what kind of changes they would like to see in the program code. You will spend much less time, making sure that your pull request will be accepted before embarking on its design (just before making an offer to your wife, I first did everything to make the answer “yes”)
Your first pull request
For the first pull request, just find any project with a suitable bug / feature and try to suggest your own improvements. Let the curators know that you are new and have nothing against their advice. If they are too busy, better look for another project. The first revision of the open source code is always difficult, so you may need the help and valuable guidance of more experienced participants. At this stage, the introduced code itself is not so important, it is important to learn how to work in an open-source project. Therefore, look for a project or person who has enough time and patience to direct you on the right path.
You may also be interested in a series of posts on how to participate in open-source projects on GitHub: https://blog.kentcdodds.com/introducing-how-to-contribute-to-open-source-be67917eb704.
Additional materials
Check out GitHub's issues for first-timers, good for beginners, good first bug (or good-first-bug), or help wanted. There are other resources for finding simple ways to participate in projects:
- twitter.com/yourfirstpr
- twitter.com/first_tmrs_only
- 24pullrequests.com
- up-for-grabs.net/#
- github.com/MunGell/awesome-for-beginners
My first pull request was a request to correct a typo in the comment. He was very small and belonged to a project that I almost never used (I found a typo, hitting the code in the debugger). It was a good first contribution, although he didn’t have much influence on the project, but I didn’t really want to continue to participate in it. I have crossed the gap between the absence and the presence of the first contribution, and this is the main thing.
Conclusion
I really like to participate in open-source projects, and I strongly advise you to experience this experience. Yes, it is not easy to start, but after you take the first step, all subsequent ones will be given much easier. Of course, not always everything goes like clockwork. The open-source community has its quirks. Do not pay attention to them, just keep working. All must succeed! Good luck!
A couple of words from the translator:
I would like to recommend another useful Kent article " Introducing: How to Contribute to Open Source ". It mentions his small course " How to Contribute to an Open Source Project on GitHub ".
Source: https://habr.com/ru/post/347066/
All Articles