@P0pMan20
It’s a wonderful feeling to find a bug in a piece of software you use and to submit a pr resolving that bug!
@zb2747
I agree, if I could start my journey over I would jump straight into Open source and treat that as my ‘projects’ vs building things on your own. Because not only are you contributing but you’re also working with others as a team. Most definitely will look good on your resume and you will for sure meet mentors and high name tech contributors and even get paid through open source. Would encourage anyone starting out to prioritize open source over building things or a portfolio for a job
@firefoxmetzger9063
I think you forgot step 0 when contributing code: Leave a comment on any issue you want to fix, state clearly that you would like to contribute a solution, and ASK(!) if a maintainer is there and willing to review/accept your work. It usually doesn't take long to get a response, gives you a general sense of the pace at which the repo operates, and saves you from contributing to dormant projects. For the first PR it will take a couple of days to set up a dev environment, get familiar with the tooling, understand the test-suite, etc. Nothing takes the wind out of your sails faster than putting in those days of work just to see the PR sitting there for months with no feedback and no merge. So before you start, make sure you have talked to maintainers (like me) before you airdrop a PR. We don't want your work to sit around and collect dust, but unfortunately, most of us have to split our time between the project and a regular job. Having clear communication on this from the start goes a long way in having fun with open source :)
@carlitos4505
Honestly, I think the more feedback you get on your PRs, the better. That means people doing code reviews care enough about you as a contributor that they’re willing to spend time going over your authored PR. It gives that much more meaning to your PR when it’s eventually approved and merged. And you can say, “I’ve contributed something meaningful to this project!”
@d00mfish
I would've never clicked if it wasnt that short. Great Video!!
@NicolaiWeitkemper
Oh yeah, getting into Linux and fixing small bugs and annoyances in the programs I used, or even just reporting them, that's how I got started.
@prabs8569
Also, just remember to check whether the project is still active or not by checking the latest pull request date and also ask the owner before solving an issue, the issue might already be assigned to someone or for any reason they may not accept your PR so prepare for that as well just in case.
@grepgrok8735
Timestamps for those interested: 0:00 - Why contribute? 0:44 - Finding a project and an issue 1:33 - Read the rules 1:46 - Form the project, make a branch 2:03 - Feeding the YouTube algorithm 2:08 - Make your changes 2:23 - Push your changes 2:28 - Open a PR that resolves the issue 2:47 - Monitor and receive feedback gracefully 3:05 - Signing off
@MrAokage
this video changed my mind about open source projects, i never knew that it was so easy to contribute, thanks dude!
@banerjee987
love this video because 1. On point 2. Time saver 3. Insightful
@deepspaceship
I started my journey with open source in 2019. Gradually I made my career in open source and now working for an Open Source company. The best part is ypu get to contribute to projects freely. There are lot of talented developers and almost every open source developer is passionate about their work. ❤️
@SagarYadavIndia
I tried. And here's the thing. I submit the pull requests, the other developers copy the change, generate their own pull request and approve their own pull request rather than approving mine. It's kind of fool's gold.
@LiamDennehy
I can't agree with this enough. The sense of achievement for adding anything of value to something YOU value is amazing. I've even had my own fork become more popular than the original project, and made it the reference implementation for an IETF RFC. Aim high, and have fun. Oh, and read "The Cathedral and the Bazaar" for a primer on how open source rewards contributors, and how contributors reward open source.
@theailateshow
Wow, finally a simple explanation for how to contribute to open source
@skeilnet
I've acquired my knowledge from the open-source community, and I actively seize every chance to contribute. Numerous individuals and companies have approached me for projects tied to one or more of my pull requests, opening up a plethora of opportunities for me. I am sincerely grateful for the enriching experiences this has brought into my professional journey.
@ToadalSimplicity
Great advice! Can’t believe I never thought to look at the dependencies of a project to find other projects to contribute to. Love that suggestion!
@Aceptron
This video alone shows that this dude knows how to do useful contributions in general.
@Littlefighter1911
I try to make bug reports instead of providing the actual solution, to keep the (minor) contributor count low so that license-wise there are no problem if someone decides to change it (I seriously had people hit me up if changing the license was ok, because I added one DLL the repository). And I seriously had one dude complaining about my bug report, that I wasn't fixing it myself and that I suck for being a security researcher who just posts bug reports on open-source projects so that they can use the unfixed bugs in their reports to say open-source sucks (of which none is true). I legitimately just had a wrong free bug when running the code "casually". I provided reproducible steps, test files, everything. In the end I fixed it in the same manner as the rest of the code has been fixed at a similar line of code, created a pull request and it still hasn't been merged. (~6 hours wasted, plus a giant "f u" in my face) Another time, I added a feature I wanted, created a pull request and basically got a "won't merge", because it simply doesn't fit the idea of the maintainer of what the project should look like. (Neither would there have been any grounds to make this feature fit, because it's nature was just not fitting) Other times I create a pull request with the message: "Please test before merging" and it gets merged so fast that it can't possibly have run through any tests. Other times it takes 2 years before my pull request gets accepted, despite it literally being just a fix where someone accidentally had swapped x and y (or rather u and v). And now to the worst offender, which is my professor at uni, wants me to rebase my 60+ commits (among which are also commits of colleagues) into 4 big commits that are actually features that rely on each other, rewrite history that way and screw up authorship of files and cause me a bunch of headaches and increased testing efforts when I'm already 1 year due to submission. Not just that but it eliminates the detailed description of each commit and thereby I need to change a bunch of files again and reconsider which stuff I put into the documentation and which not, while before it was very clear that certain bugs that have been fixed did not need inclusion in the documentation, but had a detailed explanation in source control. THAT'S my experience with open-source.
@SuperGrimmy
The best part of making PRs is in fact the feedback because you learn so much from it.
@tiamabderezai5374