Advice for those getting into OSS contributing | Hacker News Reader

Advice for those getting into OSS contributing

6 pointsTinos3 comments

I've been writing code for almost a decade now but had never really delved into contributing to OSS. I have found myself approaching the end of university with quite a lot of time on my hands and would love to try and help out.

I recently stumbled across the Ladybird browser project which is exactly the sort of project I would be interested in contributing to, however, whenever I go onto a project's GitHub page I'm very quickly overwhelmed by 10 config files, 8 folders with thousands of files, and hundreds of issues & PRs. It feels like being dropped into the centre of rush-hour Tokyo and told to find a penny on the floor.

How do you deal with getting to grips with overwhelmingly large databases? If you're implementing a new feature, how do you know what utils might already exist or what design pattern they would want you to use? It's all so much for someone just trying to help!

View on HN

Start by figuring out how to build the project and locally run what you just built. Once you can do that, you can make simple changes like fixing typos, and move up from there. If there is a guide for contributors, read through that too.

There is lots of documentation about OSS out there too, for eg:

https://producingoss.com/

If you want to get paid to work in OSS, check out FOSSjobs and their wiki. If you want to get paid to work on OSS web browsers in particular, Igalia is the place to look at, especially their coding experience internships.

https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources https://www.igalia.com/coding-experience/ https://www.azabani.com/2020/09/27/my-internship-with-igalia...

I've found it useful to have a goal when learning a big codebase - for instance, you could pick one of the issues labeled with "has repro" like:

https://github.com/LadybirdBrowser/ladybird/issues/3512

and then start tracing how that HTML turns into the wrong shapes being drawn.

Before I forget, remember that sending nice bug reports is very useful Try to include obvious reproduction steps, and be polite. Try to see how they fix it, and if you find a similar problem in the future you can try to fix it yourself. (Or just send another nice bug report that is very useful!)

Don't be shame of small fixes, like typos in docs or comments. Until you understand what are the secret weird rules of the mantainers is better to start with something short.

For starting, fixing bugs is better than new features. A bug is a bug, but a new feature may not be in the roadmap of the mantainers. Don't spend more than 2 days writing them, you are never sure if they will merge it. If they don't like it, you wasted only 2 days.

For longer bug fixes or new features, ask the mantainers before doing a lot of work.

The project is huge. My recommendation is to concentrate in a part you like and ignore the rest. Try looking at the closed PR and find a few that you consider interesting and take a look which files they modify. Look at those files and try to ignore the rest. Also look at the commit history.

This project has a lot of dependencies, so my guess is that you will need a few weekends to be able to compile it. You will have to "sudo app-get install whatever" a few times. If you get stuck, ask in the mailing list/slack/discouse/discord/issues or whatever they use for communications. Also try to explain what you have done, what is the error and be polite.

Reply on news.ycombinator.com