Open Source Contribution Etiquette

Wow, I had never heard of someone doing major reformatting, reorganizing, or refactoring on someone else's code before submitting a patch! I would say that anyone who would do such a thing doesn't understand what it means to work with other people!

I've always thought a general etiquette guide and howto for contributing to open source projects would be useful.

Hmm,<p><i>"The maintainer is in for the long-haul, and has been working on this code for longer than you have. Chances are, he will keep doing this even after you have long moved into your next project."</i><p>That might be a common pattern but it seems like it's sort-of a dead end pattern. If put yourself out there as The Maintainer in that way, you've basically said no is going to be able to make major contributions without you - going it alone become a self-perpetuating process and it's indeed not surprising that no one will stick around.<p>I have a large project that I hope to release in the next 1-3 months. I've put a large amount of effort into it. I'm also putting effort into making the code good enough that others can come on board and make significant extensions to it. Following the existing code style certainly but quite possible rearranging functionality, breaking up and rearranging function if it's useful and so-forth.<p>A VCS like git that lets everyone have the branch they like can be good here. Do what you love and inclusion in the main branch should follow sooner or later...

SCM (a la GitHub pull requests) really helps with this. When your contribution is reduced to a line-by-line diff, it becomes clear what the essential changes are (and satisfying to make the diff as short as possible).

Who does that ? Each time i had to fix something in a OSS project i touched as little code as possible. Everybody knows is no fun working with code written by somebody else.

Indeed, the code formatting style used by Mono (eg spaces before argument parens like "SomeMethod ()") is one of the biggest reasons I'll probably never contribute to it. I can't change the existing style, but it makes my eyes bleed to read, so I avoid it.

It helps to keep clear the distinction to "contributing to someone's open source project" and "writing code for an open source project".<p>The code might be open/free, but the maintainer of a given instance/repo is ultimately in charge of at least that.