My first recommendation is to send them to a project you use and care about. If you try to send a PR to a project you don't use, it's difficult for you to understand the jargon, the hidden assumptions, the vision, and other high level stuff that are obvious (or easier) if you are using the project.
* Send nice bug reports, with foolproof reproduction steps. Err on the side of too foolproof. People underestimate the importance of bug reports, but they are very helpful. Try to see how they fixed it, so perhaps next time you understand where the error is and perhaps fix it. (Sometimes navigating the project structure is hard, and it's difficult to even find the file where the error is.)
* Send PR fixing typos. Typos in the docs. Typos in comments. Typos in error messages. The nice part is that it's an easy fix, it's probably correct, and it has a high chance of being approved. (English has a few spelling variants, check that it's not just a en-uk vs en-us difference.)
It's also helpful because you must learn how to clone the project, use github (or gitlab, or the mailing list, or whatever system they are using), and how to interact with the maintainers.
* If you have a feature you want and can implement it, it's a nice PR. Start with easy and short features. Don't spend more than one or two days building it (4 to 8 hours, or even less). Nobody guaranties that it's correct, that it's in the vision of the maintainer, that the maintainer is not a moron. If it's not merged, you've only lost one or two days. If the maintainer likes the idea but want a different implementation, you've only lost one or two days.
Some people recommend to ask in the mailing list or an issue in github/gitlab if the maintainer likes the idea. My English is not so good, and some features are difficult to explain. So I prefer the alternative method of just writing the PR, but only short PR that need one of two days of work.
Be prepare to fix your PR. There are implicit local rules about the code, like tabs vs spaces, trailing spaces, indentation, ... try to follow the local conventions. Also, you may need to add some new test for the new feature or a regression test, and other testing. So expect that sometime you will need additional work to polish the PR.
* For big features, discuss them with the maintainer first. Again, nobody guaranties that it's correct, that it's in the vision of the maintainer, that the maintainer is not a moron.