Why Contribute?

Contributing to open source is a fantastic way to collaborate and build connections with other developers. It also helps a lot with imposter syndrome; it gives you great practice for your first developer job and allows you to tackle progressively more challenging tasks. In addition, a lot of open source companies look to their contributors when hiring for a position, so the connections you build through open source can be valuable to your career.

What Do I Work On?

Look for low-hanging fruits in the issues, i.e. something easy enough to change and test.
If there aren't tons of issues, then take a stab at improving test coverage in the repo.
I'd always recommend opening an issue before submitting a pull request so you get feedback on your proposed changes before going through the effort of implementing those changes.

What If I Get Stuck

A really important part of being a developer is learning to navigate a code base. I enjoy using tools like ripgrep and Sourcegraph for finding key words in either a local repo (ripgrep) or remote repo (Sourcegraph). Both support regular expressions, so you can get very specific with the sequences you're looking for. I definitely recommend getting comfortable with these tools and learning to backtrack to find solutions.

Of course, with any new code base you'll get stuck and need help. Don't worry, most open source projects have communities associated with them that you can find easily on their Github or website. Joining their community and asking questions or asking questions as issues or discussions on the repo are great ways to get answers to your questions. Note that nobody is going to spoon-feed you, so make sure you've checked the docs for your language when applicable and that you've tried to answer your own question by searching through their code and documentation.

If anything is unclear about how to run the program or get it set up for development, definitely ask!

What Do I Need to Know?

• Git, more specifically:
  • conventional commits (follow the standard used in the repo you're contributing to)
  • Merge vs Rebase
  • Squashing commits
  • Cherry picking*
  • Partial commits*
• How to create an issue
• How to create a pull request
• Writing user stories* (helpful for giving an issue more context in few words)

Don't forget to check if they have a contributing.md file that specifies the format for issues, PRs, etc.
You can also look at previous PRs that have been merged to get an idea of what has been accepted in the past.

*nice to know, not need to know

Let me know in the comments if there's anything I missed!