[SXX]

You don't start participation in project from major architectural changes. It's always take time to learn code base and find out about design advantages/flaws/etc.

Problem with art is that unlike with bugs nobody even know what needed and what isn't. As result there is really low guarantee that art you can make actually going to be used.

[lsc]

my argument is that art isn't fundamentally different from code in this respect.

If you have a very small patch that obviously fixes something broken and doesn't change much else, you are gonna have an easy time, be that change art or code. And as you said, either way, that's how you should probably start. Little things.

Either way, if you want to make major changes, be those changes in art or code, you are going to meet resistance, especially if you don't already have social capital built up in the project by making lots of smaller changes.

Getting your changes upstream in a open-source project is a fundamentally social process. If you show up with a bunch of patches and then leave, well, a lot of your work is probably not going to get used. Hell, even if you do everything right, a lot of your work isn't going to get used. That's just how things work.

[SXX]

I agree with you that art isn't that different than code in community game development. My point is that in case of art most open source project don't even try to actually accept and review contributions at all.

Still I can't agree that upstreaming of code is anything like hard in case of most open source games. There is only few projects that feature complete and have plenty of programmers. Of course such projects usually have higher requirements to contributors, but most of projects are newbie-friendly as they always happy to see more developers.