I started because I found a couple of critical bugs in a query language parser I was trying to use. I think it made a good introduction -- but I still had to get over the same instinctive feeling of "oh shit what if this is actually garbage and I'm wasting the maintainers' time" on my own and stick my neck out. If you can start with something straightforward that's probably for the better, but it really does just come down to putting your work out there and seeing what other people have to say about it.
Also: this may not apply so much to larger projects but if you drop a pull request on a smaller repository you're probably going to make the maintainer's day, whether or not it needs more work before it can be integrated. Seriously! You're telling someone you care enough about their work to help make it even better! Who wouldn't deal with a little back & forth to iron out details for that?
Documentation is easy but there's no reason you shouldn't go for code if you feel up to it. Many projects tag "good first issues" or the like; I've had a couple small feature additions there for a while. If either of those strikes your fancy I can work with you on hammering a pull request into shape.
Junior is what you make it.
I love your comments. haha
You're right, a lot of this comes with practice. Documentation is a strength of mine but that's really copping out if I'm looking for feedback on coding.
And good point about dropping PRs into lower-traffic/small repos. I had not thought about that. I'll be sure to ask for pointers when I start sending them. Currently in a crunch trying to kludge together a small site.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.