* Did they found a bug? Can they fix it?
* What is a pain point? Can they add a feature to solve it?
* Do they need to use the project in another platform/configuration?
* Does the project have some easy bugs/issues that they can solve?
Always start with small changes, perhaps only 1 or 2 days of work (or less, sometimes 2 or 4 hours are enough). You are never sure that the owner/maintainer is going to merge it. Or if they have weird requirements. Or if they don't like the change (for good or bad reasons). Or if they have a better option in development. If you invest less than 2 days, it's not big deal if it isn't merged.
When submitting a PR, mention what it’s for, it’s written in the style conventions of the project and language, and that it’s got tests!
Lastly, I realize that these types of questions that a true rookie asks because once they realize how obvious it is and then will move on.
I often place beginners, very beginners, and maybe some reluctant junior developers into a room and give them some exercises. I like to include some open discussion on side projects, OSS projects they use, the fact that GitHub is also a social network and things like Glitch and Repl.it exist to be shared. OSS is not just "open", it is social. Good open source software to me begins with a discussion of what they consider to be in good taste.
1. Set up a bunch of accounts on GitHub or GitLab, or whatever. It's better if they have a preference for one and don't use the other - make them use the one they're least familiar with. Get them used to using things they're not familiar or comfortable with doing. Sound familiar?
2. Divide the group into equal sizes if you can. If the group is prime, then it is also abelian (bad joke). I let groups assimilate and trade with each other. The macrocosm of tech's demographic tends to reify itself in microcosms as well, so you'll notice some groups get larger than others but some reach peak efficiency at specific sizes. This is good for you to know if you're in management. It's okay to let a bunch of beginners be without anyone in their group who has experience, sometimes they end up being the dark horse in the race.
3. So you have a bunch of groups, give them an exercise that has nothing to do with whatever they're supposed to be doing. Main idea: You're trying to show them how good practices can be interdisciplinary or better, that they know how to think, organize, and collaborate their efforts on new things. If it's a bunch of quants, make them use Figma or Sketch and design a layout. If it's backend, make them do frontend. If they're UI/UX give them a bunch of problems from https://projecteuler.net/
4. Now, the task for all groups is to present something by the end of the session whether it is finished or not. A lot of the time is spent teaching other how to set up their account, doing basic version control, picking a language to choose, how they're going to architect the whole thing - a lot of time is wasted trying to optimize their time. This is a good lesson and also shows people how they lack fundamentals. Junior devs tend to try to assert authority and have it backfire almost immediately. That's why they're junior developers still.
5. So some time rolls by. About the halfway mark I check in on their repositories not their team. I want to see what work they've committed to more than what they plan to do. It's also good for me to know how they catalog their mistakes and what sort of basic documentation they provide themselves out of utility rather than obligation.
6. Time's up. Let's present. Says a lot about how a team works by who does the presentation. You'll notice some people have become part of projects where they know they'll shine rather than try to struggle with a team where they know they won't succeed, even if there's nothing to risk. This says a lot about the person's appetite for code.
7. Now, the optional flavor for this exercise is to have them develop a competing app in an hour. This is obviously a questionable and risky thing to ask your team to do. My opinion is that I've hired the right team and I believe in our culture and I already know our competition so its fine. But let's say, we want our team to build a competing app - how would they do it? They already know what they hate about our company or the work they do. This exercises lets them call the shots and give themselves fake titles and lets them dream a bit. Good, I want to foster their growth here, not extract work out of them like some kind of time vampire. I like to have them pitch to each other and just try on the shoes of someone who will be someday more than what they are.