One important thing to dispel about open source is the idea that good contributions are about galaxy-brain level PRs. Contributions can happen at all level, from non-technical to technical, from reporting issues to opening PRs to solve them. And when it comes to PRs, the gamut is large: writing documentation, adding test coverage, suggesting micro-fixes or refactors are all good and valuable ways to contribute.<p>As you contribute more to a given project, you become more acquainted with the lay of the land, which in turn opens up more opportunities to contribute to open problems.<p>Long story short: contributions don't have to be complex and deeply technical to be valuable, and you gotta start somewhere. Pick a project you're interested in or look for issues needing attention (for example, via `Good First Issue` labels on Github), try something out and have a chat with more active maintainers. They'll show you the ropes and get you started!
Easy, don't try to contribute things too far above your skill set. If a codebase is too complicated, avoid code modifications. Instead of offering a fix, provide easy to follow step by step records of how to trigger a bug. Help an organization with documentation. Help out with trying to manage a bug tracker. When making changes keep them simple. As another comment points out there are often labels which indicate what tasks could be easy. That includes "Good First Issue" as well as "First-timers-only" labels.<p>Quite a while back I wrote <a href="https://zynaddsubfx.sourceforge.io/contribute.html" rel="nofollow">https://zynaddsubfx.sourceforge.io/contribute.html</a> which walks through various levels of complexities and how to get started. Other open source projects may have similar getting started guides.
Start by running the project yourself on your local machine, if possible. Go through the documentation and see if something can be improved: documentation is an overlooked aspect but key for a good projcet. Helping on improving documentation is mostly welcome.<p>By reading and improving documentation you get to better know the project. Give it a try on you machine and interact with it. If you have not seen something that can be improved technically, go to the "issues" page and see what are the bugs I there, sometimes owners tag some of the issues as "good first bug", those are easy to tackle and help you get to setup a development environment for the project. Helping on Open source does not require you to be smart, dedication and willingness to help is more important most of the time.
Curated lists. You can definitely add value and most times you don't need to be an expert.<p>A good place to start: <a href="https://github.com/slowernews/awesome-open-source-by-country-or-region/issues/6" rel="nofollow">https://github.com/slowernews/awesome-open-source-by-country...</a>