
Open Source Contribution Etiquette - rayvega
http://tirania.org/blog/archive/2010/Dec-31.html
======
ScottBurson
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!

~~~
knieveltech
It happens although I'd like to believe it's rare. I perpetrated the most
glaring example of patch refactoring I've ever seen.

The scenario: \- Original maintainer's module code totally ignored the code
style conventions for the larger project it was a part of. \- Module
maintainer had been dragging heels on a raft of bugfixes, module stuck in beta
limbo for six months. \- Boss says we need this feature (cleaned up and
stable) in our codebase by the end of the month.

My play: I refactored the codebase to meet larger project coding style
standards, patched every bug in the issue queue, added a suite of unit tests
and submitted the entire thing back to the maintainer.

Maintainer's play: The maintainer opted to reject my patch on the grounds he
preferred his personal coding style to the project standards.

Endgame: I promptly re-rolled the patch as an addition to another related
module, got the code committed to that project, posted an issue to the
original maintainer's queue indicating his module was deprecated. Last time I
checked in dude's module was still buggy and he was taking flack from several
people involved with the larger project for being a cowboy with the coding
standards.

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

------
joe_the_user
Hmm,

 _"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."_

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.

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.

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...

~~~
johndar
It depends. If you are the main author of a large project, and you look
forward to extend it by taking contributions in a direction that carries _any_
meaning to you, integrating code at random won't magically result in a better
project.

As the author an maintainer of several small FOSS projects, I rarely receive
pull requests that I can merge right away. In that sense, a distributed VCS
doesn't really improve over the patch-by-mail approach for random
contributions (it _does_ helps cooperation among regulars however).

I can also tell you right away that a FOSS project without direction or
maintainer quickly dies, independently of the VCS. Successfull forks are very
rare. Mostly, projects with good potential but no maintainer get simply dumped
and reimplemented by another programmer.

If you are a maintainer, you will appreciate all the points the authors is
making. If you are making a contribution, adhering to all the points will
increase the odds of your change to make it quickly and improve the software.

Also, conversely as a contributor, I don't spend time on projects which have
no maintainer or lack direction anymore. Having the source of a project
(especially large) sounds useful at first, until you realize that maintaining
it without the inner knowledge is a daunting task. It only makes sense if you
are willing to use it extensively (and become the new the-facto maintainer).

~~~
joe_the_user
I'm mostly saying that it seems useful for a maintainer to offer those aiming
to contribute a path towards doing more than just fixing bugs.

~~~
johndar
There's no need for that. Users/contributors will do whatever they want with
the source already. That includes hacking the source for private purposes
only. Github is the pinnacle of that attitude (which in my opinion is not
_social_ coding at _all_ \-- but I digress).

Of course, the articles misses an important point: talking to the
maintainer/author first. If you were about to do a big change, would you know
if there were any chance to be integrated first? Maybe knowing if someone is
already working on it? (heavy refactoring comes to mind). I've gained precious
insights about design by simply talking to authors before starting to work on
a contribution, saving my time countless times.

If your intention is doing a change _no matter what_ , then you're not really
interested in _contributing_.

------
Sidnicious
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).

------
mariusmg
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.

------
barrkel
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.

~~~
xsltuser2010
Maybe it would be a good idea not only to have coding standards, but also
automatic handling of auto-formatting code when checking in. If you have a
highly flexible coding style system like uncrustify for example, and check ins
would be guaranteed to be automatically formatted, you could simply tell vim
or emacs to format it with your coding style when opening, and then auto-
format it for check in.. I know it's oversimplifying, but maybe it would help
some people.

------
dedward
It helps to keep clear the distinction to "contributing to someone's open
source project" and "writing code for an open source project".

The code might be open/free, but the maintainer of a given instance/repo is
ultimately in charge of at least that.

