Well, the idea is that if you start working on a project specifically because it is noobie friendly you are likely to burn out quick since you don't have that itch you are scratching.
I think the parent is correct in that you should try to work on projects that scratch an itch. If it turns out it is a hard community to work with then fork it or move on to your next itch.
If it turns out it is a hard community to work with then fork it or move on to your next itch.
Some people might unlimited energy to program and infinitely thick skin. I think a lot of people find putting energy into a project that rejects their efforts to be somewhat traumatic and something that can impel them to give up rather than bounding on to this next adventure.
I agree that getting involved with a project that interests you should be one factor in choosing what to involve yourself with. But the OP said "any of them!" concerning what project to get involved with where as I'm arguing one should be selective and that people involved in Open Source already should be giving some guidance on the question beyond just "whatever you want".
I think this is a bit of a non issue. Wouldn't a bad community or developer become evident when you started looking around at how to help and contribute to the project?
Just recently I decided I was bored with my routine at home and wanted to challenge myself. So I set a task: pick a public repo that I don't already maintain (preferably that I use), find a bug I would like to see fixed (emphasis on would like to see the bug fixed), and to fix it.
I ended up choosing a program that I use but is written in a language I'm not familiar with. Regardless, I jumped right in.
First I looked around for any mailing lists or chat rooms where development discussion is carried out. I joined and asked how I can help, and was directed to the bug tracker and told to go nuts. I can see how this can be a daunting task, but I found the easiest way forward is to put those feelings of being overwhelmed aside and to just start. I cloned the repo and grepped for a tag I hoped would get me to the code I needed, luckily it was a good guess.
I spent the weekend reading the code for no less than three different projects and learning a lot about erlang, and by yesterday evening I had a patch created and a pull request submitted. And I feel fantastic for it and am looking forward to setting a similar challenge next weekend.
My point is that I think part of looking around the project and bug tracker should help you figure out what the attitude of the Dev team is like. I don't doubt there are sour devs our there but IMO they are few and far between, more likely is the unresponsive maintainer who lost interest in the project but still has the keys to the kingdom.
What's the worst case scenario? You create a patch and the project maintainer refuses to merge it? If he doesn't provide good reasons for not wanting to merge it, he looks bad. If he says your code quality needs improvement you can ask for specifics and learn some new tricks. If he says he just doesn't want that feature then leave your code up on github and see if other people start advocating for having your issue merged. This seems like a tempest in a teacup to me.
When you are just starting out, you don't know what is normal and you can't tell whether the project is poorly run or whether you are just bad at programming and should give up.
I think if you don't know what's normal yet, set the bar.
What I mean is, when you're trying to contribute, how do your interactions with that project and the developer(s) make you feel? At the end of the day, if you're not enjoying yourself and what you're doing, drop the project and find something you enjoy. Might be a different more-receptive project, but it might be a different hobby too, I would encourage you to try multiple project before giving up though.
> "if you don't know what is normal yet, set the bar"
What do you actually mean by this? I'm pretty sure I'm misreading you here.
What I'm reading is "when you come into a new organization and you see people doing things that make you feel bad, force them to change their culture." However, arguing against that feels like arguing against a strawman because it seems obvious to me that you can't effectively change an organization as a random novice and that trying to do so is going to make people really dislike you. Even if it would happen to work, doing it requires being the sort of person thats willing to be called an asshole.
Your level of energy for programming does sound pretty impressive compared to mine. I will admit that if everyone else has energy to churn out patches willi-nilli, worries about whether they would get pushed would not be a non-issue. I'm not so sure that's true, however.
I think the parent is correct in that you should try to work on projects that scratch an itch. If it turns out it is a hard community to work with then fork it or move on to your next itch.