In the virtual PyCon hallway track, a newcomer to the industry said he'd like to get into contributing to open source, and asked for my advice. So here's approximately what I said.

Why and how

It's like deciding you want to join a band, in a few ways:

1. Different people have different reasons to do this, such as curiosity, socializing, learning something specific, making a particular kind of thing, career ambition, or giving back to an environment that's nourished you. (That last one: maybe less common for musicians than open source contributors.)
2. Choose people you'd enjoy working with, whose styles suit you.
3. Consider the "genres of music" that you'll enjoy hearing and making. In software, that might mean the subject matter domains or the languages/frameworks in use. If you are particularly interested in playing rock guitar, then even if the a capella group near you is friendly, you'll likely be unsatisfied joining them. Similarly, if you're most enthusiastic about frontend web development for games, then the team working on a Fortran compiler will likely not be particularly interested in helping you find the crossover niche that combines them.

So I asked about his motivations. He said that, at his job, the way work is split up, he works on his own a lot and is eager to work on a team where a more expert developer will give him feedback, and figures open source contribution is an opportunity for that. Seems reasonable!

I advised him to strongly consider the Recurse Center programming retreat (6 weeks or 12 weeks, currently entirely online) which would be a concentrated approach to learning with peers, including pair programming with more experienced developers. (And, if he were available for a 3-month paid apprenticeship, I'd recommend Google Summer of Code or Outreachy.) But if you can't take 6-12 weeks off from work/school, a more gradual & steady open source participation cadence probably works better.

Choosing projects to try

A thing I should have said to him and forgot to: if you frequently attend local (geographic) meetups for programming stuff, and there's a friendly and responsive open source maintainer in that group, or your local friends already contribute to a particular project, that's a great place to start! Having local pals you can learn from and with is profoundly helpful -- for onboarding, morale, and working through confusing problems.

In case you don't know of a project where local folks will be helpful: start listing the open source stuff you interact with or use. Think broadly and include browser extensions, mobile apps, command line tools, work and personal stuff - and think about the "genres" you'd like to work in, but don't 100% limit yourself to stuff in languages you already know.

Then: to make a shortlist of projects you might like to join, check for interpersonal style and responsiveness.

For each repository, pick 5-10 recently commented issues and skim them to assess how maintainers interact with contributors and users. Would you enjoy working with these folks? (Your preferred style may vary from mine! Maybe you prefer sarcastic quips to verbose earnest invitations and explanations!)

And: pick 5-10 patches/pull requests that are open, and notice who's waiting for whom right now. Are maintainers mostly waiting for contributors to revise/reply, or are contributors mostly waiting for maintainers to review/reply? If the latter, then odds are you'd be in that queue too.

So: now you have a shortlist of responsive-to-PRs projects whose maintainers you'd enjoy collaborating with. Start exploring those.

Your first contribution: testing & bug commenting

I'd say: DON'T start by trying to find a bug to fix. Instead, a good way to start is to go through old (like, more than a year old) open issues/bug reports and test whether they are still reproducible in the most recent release and in a build from the most recent commit on the main branch. (This will require you to get your development environment set up locally.) Since this is a project you use, you have better context for the bug reports -- what users are trying to do and what they usually expect -- so you can do a better job filling in missing assumptions in incomplete bug reports, as opposed to trying to work on a project you don't use at all. Your first contributions to the project can be comments saying that particular bugs are no longer reproducible and can be closed. If this is true then maintainers will be pretty happy to see your work!

And as you go through those, you'll learn about the tool -- how it works, what people want from it, how it's improved recently, and so on. Chances are, at some point you will find a reproducible bug and get to thinking "I bet I could fix this." And that can be your first pull request/patch. At this point you'll have a basic understanding of what the maintainers care about and how to present and frame your patch, so they'll be more likely to take it, and they'll already know your username from your bug review work, so they'll be more likely to prioritize reviewing it.

There you go

That's my advice, as of mid-2022, for someone who's already got a day job in programming and seeks professional mentorship. I know it probably differs from what many guides for aspiring contributors suggest. Specifically, I'm not pointing to any automated repository assessment tools, because I think none of them can capture the "do I like the conversational tone here?" criterion. And I rarely find the geography factor mentioned in other guides. Hope this helps!

P.S. If you got this far and you want more guidance, Open Advice is great: "a knowledge collection from a wide variety of Free Software projects. It answers the question what 42 prominent contributors would have liked to know when they started so you can get a head-start no matter how and where you contribute."