January 19, 2018 at 18:25How can a beginner take part in open source development?
- Transfer
Last time I published a post about the difficulties that developers face when trying to participate in open source projects. I did not want to leave this problem without a description of a possible solution, so this time I translated for you an article by the famous open source activist Kent Dodds. In the article, the author shares several interesting life hacks - I hope they will help some of the readers to get more benefit / get more pleasure from participating in open-source projects.
After my recent post, “For those who have this for the first time,” I received a lot of letters and messages asking: “In what open project will you advise to participate?” In this post I will try to answer this question, as well as formulate several recommendations regarding the first steps in open source.
In its most general form, the answer is:
Personally, I am most satisfied with working on projects that are important to me and my friends. The second key to success is working on an ongoing basis. Regular work on a project will require an understanding of the features of using the software and the problems for which it was created - getting to know the software from a user's perspective helps a lot.
What open libraries, frameworks or tools do you use most often? Maybe you are working with Grunt, Gulp, Webpack or Browserify, and it seems to you that they could be improved or documented more accurately. Or, probably, you are using the React library or the Angular module - you can also polish them a bit. You probably use some kind of open source software - and its improvement can help you in some way.
As soon as you have decided on the project in which you will participate, the second question arises: "And from which side to take it"? Many projects have a CONTRIBUTING file . Looking into it, you will find instructions for participating in the project. If there is no separate file, then the corresponding instructions can be in README (usually located on the project home page). And if there is neither one nor the other, then you can send a pull request to add at least the skeleton file CONTRIBUTING.md to start negotiations on adding complete instructions.
Get to know the project closer. Reading the documentation is good, but I like to learn the project by code more. My favorite way is to get into function calls through the debugger. For example, what happens if you call angular.module?
After 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 just by adding console.logs). Do not worry if something is left incomprehensible on the move. Do not give up - you can do it!
After you have learned the standards and procedural features of participation in the project and got acquainted with the principles of its work, it is time to determine the changes necessary for the project. I recommend taking a look at the existing problems and comment on those that seem interesting. After talking with the curators, you can find the best solution - and then form a pull request.
If you have your own thoughts on fixing a bug or feature that you would like to implement, I strongly recommend that you first discuss it with the curator (s) on the GitHub issue . Maybe they will say that it lies outside the scope of the project’s interests or is already in development, or 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 taking up its design (just like before making an offer to my wife, I first did everything so that the answer was “yes”)
For the first pull request, just find any project with the appropriate bug / features and try to suggest your improvements. Let the curators know that you are new and have nothing against their advice. If they are too busy, then look for another project. The first refinement of the open source code is always difficult, so you may need help and valuable guidance from 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 guide you on the true 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 tickets marked with first-timers-only, good for beginners, good first bug (or good-first-bug), or help wanted. There are other resources for finding easy ways to participate in projects:
My first pull request was a request to correct a typo in a comment. He was very small and belonged to a project that I almost did not use (I found a typo, sweeping the code in the debugger). This was a good first contribution, although it did not particularly affect the project, but I was not particularly keen to continue participating in it. I stepped over the gap between the absence and the presence of the first contribution, and this is important.
I really like to participate in open source projects, and I strongly recommend that you experience this experience. Yes, it’s not easy to start, but after you take the first step, all subsequent ones will be much easier. Of course, not everything goes smoothly. The open source community has its own quirks. Do not pay attention to them, just keep working. Everything will surely work out! Good luck
I would like to recommend another useful article by Kent, " Introducing: How to Contribute to Open Source ". It mentions his short course, " How to Contribute to an Open Source Project on GitHub ."
After my recent post, “For those who have this for the first time,” I received a lot of letters and messages asking: “In what open project will you advise to participate?” In this post I will try to answer this question, as well as formulate several recommendations regarding the first steps in open source.
In its most general form, the answer is:
You can make the best contribution to the development of the software that you use regularly.
Personally, I am most satisfied with working on projects that are important to me and my friends. The second key to success is working on an ongoing basis. Regular work on a project will require an understanding of the features of using the software and the problems for which it was created - getting to know the software from a user's perspective helps a lot.
What open libraries, frameworks or tools do you use most often? Maybe you are working with Grunt, Gulp, Webpack or Browserify, and it seems to you that they could be improved or documented more accurately. Or, probably, you are using the React library or the Angular module - you can also polish them a bit. You probably use some kind of open source software - and its improvement can help you in some way.
First steps
As soon as you have decided on the project in which you will participate, the second question arises: "And from which side to take it"? Many projects have a CONTRIBUTING file . Looking into it, you will find instructions for participating in the project. If there is no separate file, then the corresponding instructions can be in README (usually located on the project home page). And if there is neither one nor the other, then you can send a pull request to add at least the skeleton file CONTRIBUTING.md to start negotiations on adding complete instructions.
Get to know the project closer. Reading the documentation is good, but I like to learn the project by code more. My favorite way is to get into function calls through the debugger. For example, what happens if you call angular.module?
After 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 just by adding console.logs). Do not worry if something is left incomprehensible on the move. Do not give up - you can do it!
After you have learned the standards and procedural features of participation in the project and got acquainted with the principles of its work, it is time to determine the changes necessary for the project. I recommend taking a look at the existing problems and comment on those that seem interesting. After talking with the curators, you can find the best solution - and then form a pull request.
If you have your own thoughts on fixing a bug or feature that you would like to implement, I strongly recommend that you first discuss it with the curator (s) on the GitHub issue . Maybe they will say that it lies outside the scope of the project’s interests or is already in development, or 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 taking up its design (just like before making an offer to my wife, I first did everything so that the answer was “yes”)
Your first pull request
For the first pull request, just find any project with the appropriate bug / features and try to suggest your improvements. Let the curators know that you are new and have nothing against their advice. If they are too busy, then look for another project. The first refinement of the open source code is always difficult, so you may need help and valuable guidance from 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 guide you on the true 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 tickets marked with first-timers-only, good for beginners, good first bug (or good-first-bug), or help wanted. There are other resources for finding easy 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 a comment. He was very small and belonged to a project that I almost did not use (I found a typo, sweeping the code in the debugger). This was a good first contribution, although it did not particularly affect the project, but I was not particularly keen to continue participating in it. I stepped over the gap between the absence and the presence of the first contribution, and this is important.
Conclusion
I really like to participate in open source projects, and I strongly recommend that you experience this experience. Yes, it’s not easy to start, but after you take the first step, all subsequent ones will be much easier. Of course, not everything goes smoothly. The open source community has its own quirks. Do not pay attention to them, just keep working. Everything will surely work out! Good luck
A few words from the translator:
I would like to recommend another useful article by Kent, " Introducing: How to Contribute to Open Source ". It mentions his short course, " How to Contribute to an Open Source Project on GitHub ."