Comments on: 8 steps for fixing other people’s code

By: Michael Harrison

Michael Harrison — Mon, 01 Mar 2010 12:53:15 +0000

@Nic, thanks. I do think the tutorial will be valuable. I’ve forked projects on github, but not to contribute changes back into the main project, but rather just for my own selfish needs. There are a lot of good tutorials on offer, though, so it will be a tough choice deciding which to attend.

I look forward to meeting you at RailsConf whether I make it to your tutorial or not.

Cheers!

By: Dr Nic

Dr Nic — Sun, 28 Feb 2010 23:06:46 +0000

@Michael, I did indeed borrow this post’s title for the tutorial on Open Source! I wrote this post a long time ago; I think by the time June 2010 rolls around it will be about 3 years old. Since then we’ve seen our entire ecosystem move to git or hg, with sites like github ruling our workflows.

Nonetheless, the 8 steps are the same. Except we now have better tools and a wonderful, healthy mentality of “fork this” rather than “this is my project.”

If you’re a happy open source hacker, you don’t need to come. The corridors of the
conference are for you!

In fact it is so easy now to start new projects, and get involved in helping other people’s projects, that the next question to discuss is “how do I cope?” I won’t cover this topic, since I busted out my thoughts last year at FutureRuby.

By: Michael Harrison

Michael Harrison — Sun, 28 Feb 2010 22:32:15 +0000

I noticed you’re running a tutorial at Rails Conf in June 2010 with the same title: “8 Steps…” So, to be obnoxious, can I ask what extra wisdom and information I get for attending that tutorial over reading this post?

By: The Puerto Rican Rails Dude » Blog Archive » No Rest For The Unemployed

Wed, 27 Jan 2010 04:25:55 +0000

[...] are any open issues on their GitHub page. A few years ago, Dr. Nic wrote an excellent post titled “8 steps for fixing other people’s code” that inspired me to start finding features or defects that I can [...]

By: Dr Nic

Dr Nic — Tue, 26 Jan 2010 22:15:27 +0000

@hron – yep, this is an old article and could benefit from some git specific thoughts/references

By: hron84

hron84 — Mon, 25 Jan 2010 10:58:08 +0000

I missing an alternative doc for github users. Modern ruby developers uses github…

By: uberVU - social comments

uberVU - social comments — Sun, 17 Jan 2010 08:43:19 +0000

Social comments and analytics for this post…

This post was mentioned on Twitter by fab_can: ejoied reading the 8 steps for fixing other people’s code http://bit.ly/2lQX3U...

By: Files Search

Files Search — Tue, 29 Dec 2009 13:41:28 +0000

http://www.picktorrent.com

By: Paul Hummer

Paul Hummer — Tue, 08 Dec 2009 02:55:00 +0000

Submitting a patch through Launchpad’s Bug Tracker is probably not the most ideal way to get your patch merged. Since you’re already using Bazaar, you should push your branch to Launchpad and then, through the web ui, propose the branch for merging into the trunk branch.

By: johnnie

johnnie — Thu, 03 Sep 2009 22:24:31 +0000

Thanks for a nice article.

In the second black code box of step three, the first line reads “rm -rf XYZ”. I guess this is not needed if in the previous step you indeed use “svn list” and don’t actually do a checkout.