

Contributing to Open Source projects - mqt
http://brad.livejournal.com/2409049.html

======
jrockway
Github solved this problem. Everyone knows how to contribute to a Github
project. Click the fork button, commit your patch, send pull request.

~~~
krainboltgreene
I wonder if you're being sarcastic? Had you said that to me two weeks ago I
wouldn't know what the hell "fork", "commit", and "pull" had to do with
contributing.

Git is hardly the _end all be all_.

~~~
jamesbritt
Even for people git-aware, there's a bit more involved.

Most people are probably happy to get patch submissions, but there's some work
involved in accepting them.

Generally, project owners want to see a test accompany any change to
demonstrate that a bug was fixed or that new behavior does what's claimed.
There may also be coding standards to follow, and (ideally) some documentation
for new code.

If you omit these things when you submit a patch or issue a a pull request you
may still think you're doing the project owner a favor, on the premise that
something is better than nothing, but reviewing your submissions and checking
that it is correct, and possibly cleaning up your code and adding tests, may
end up being more work than it's worth.

Git and github have removed some obstacles to contributing, but there are
still assorted details one has to look after.

~~~
jrockway
_Generally, project owners want to see a test accompany any change to
demonstrate that a bug was fixed or that new behavior does what's claimed.
There may also be coding standards to follow, and (ideally) some documentation
for new code._

If the project owner really wants the patch, they will fix these details
themselves. In my experience this is how project owners reject patches that
they don't want; make the submitter do more work than he is willing to so that
the patch silently dies.

Personally, I will usually ask a submitter for a test case and some docs...
but if I don't hear from them (or hear, "works for me, no time"), I will just
write them myself. Same for style issues; easier to just fix them myself, then
I know that the style is exactly what I want.

Github, at the very least, eliminates any technical reason not to contribute.
Social issues are largely the same; although back-and-forth is a lot easier
when you both have access to a public repository. (Who likes attaching the 8th
iteration of a patch to email? Not me.)

~~~
durin42
Seriously? I'd much rather get a potential repeated contributor who can follow
my style than clean it up without asking him to do it. Double for tests: I
frequently can't figure out exactly what the best regression test will be and
the contributor needs to make it himself (though that may be a special case of
my VCS work). Pull requests actively make commenting on a patch harder than a
patchbomb in email. The fork queue (imnsho) is even worse, as I've had people
just assume I'll see it and just take it from the fork queue page.

Feel free to write me off as a cranky old fart - I've been doing OSS long
enough to remember Subversion as a wonderful thing on the horizon and the pure
joy of its relative speed. This is all based on my mostly-poor experiences
with GH preventing a community domain forming by causing nobody to talk
outside of their commit messages, which is a huge loss.

------
mhansen
Node.js is a great example of how to do this right. They walk you through the
exact steps needed to submit a patch.

<http://nodejs.org/#contributing>

------
dgl
One key difference which the post doesn't really touch on is that when it's a
company everyone's interests are more closely aligned (or at least should
be...).

On the other hand even if you find where to contribute to with open source you
can't be as sure your patch will be taken.

(Although as mentioned on LWN: <http://lwn.net/Articles/379109/> it seems
Google have managed to fork libjingle, so even Google can't get this right.)

------
benatkin
I found Giles Bowkett's for-sale video, which covered contributing to open
source along with many other things, helpful. Contributing to the open source
community way easier than it sounds. Contributing to open source code,
specifically, in a noticeable way, is probably harder, but not that much
harder.

[http://gilesbowkett.blogspot.com/2010/03/programmers-what-
to...](http://gilesbowkett.blogspot.com/2010/03/programmers-what-to-do-if-you-
get-fired.html)

It didn't even take a week after I watched it for me to start implementing his
suggestions.

