alindeman · May 25, 2014 17:40 · eldondev · May 26, 2014
diff --git a/gistfile1.txt b/gistfile1.txt
 > Dan Buch of Pittsburgh aka meatballhat suggested I contact you. I'm
 > transitioning into Ruby and Rail from another completely unrelated profession
 > and I'd like to contribute to open source projects as much as I can. I think
 > it'll help me move beyond tutorials and books. I've gone through several of
 > them already, including Michael Hartl's free tutorial as well as Pragmatic
 > Programmers' Programming Ruby. Do you have any recommendations?

 It’s great to hear that you want to contribute to open source! I had dreams of
 contributing to Rails itself and maybe even become a regular contributor.
 However, the framework code itself was completely overwhelming to me as someone
 just learning. I focused on exploring gems that were commonly used alongside
 Rails. I eventually landed on RSpec and ended up being a core contributor for
 some time.

 Popular open source projects often have many issues reported against them, but
 the maintainers also frequently have difficulty triaging so many of them. In
 some of the cases, it’s very clear what’s going on and how to fix it. In other
 cases, the issue has been reported by someone lacking enough context to debug
 it effectively. I think this area is where new open source contributors can
 shine, especially if you like the thrill of the hunt: find issues where detail
 is lacking (e.g., no error message, no backtrace, no version) and ask the
 original reporter to provide some of these details. If there is enough detail
 to figure out how to reproduce the issue yourself, but there isn’t yet an
 automated test case, try writing one and making a pull request with just the
 new test. Even if you aren’t comfortable fixing the issue, an automated test
 case that’s failing (“red”) is a huge help and will likely motivate the core
 contributors to fix the issue sooner. And furthermore, the test doesn’t
 necessarily have to be the best test: just the fact that it demonstrates the
 issue in a way that everyone can reliably reproduce is good enough.

 By writing automated test cases for bugs, you’re also exploring the code base,
 getting familiar with the conventions, patterns, and existing design. Soon
 enough, it’s likely that you’ll have enough context to start adding new
 features or fixing bugs yourself. And that was probably the goal all along, but
 I think it can be too overwhelming to dive in all at once sometimes.

 Some folks also recommend writing documentation as a way to get started. I’m
 skeptical that this actually works in practice, at least for certain kinds of
 documentation, but certainly it is nice to look at projects with fresh eyes and
 improve the documentation in such a way that it would have made your life
 easier upon first using it.

 Hope this all makes sense. I’m happy to go into more detail. Good luck!
	> Dan Buch of Pittsburgh aka meatballhat suggested I contact you. I'm
	> transitioning into Ruby and Rail from another completely unrelated profession
	> and I'd like to contribute to open source projects as much as I can. I think
	> it'll help me move beyond tutorials and books. I've gone through several of
	> them already, including Michael Hartl's free tutorial as well as Pragmatic
	> Programmers' Programming Ruby. Do you have any recommendations?

	It’s great to hear that you want to contribute to open source! I had dreams of
	contributing to Rails itself and maybe even become a regular contributor.
	However, the framework code itself was completely overwhelming to me as someone
	just learning. I focused on exploring gems that were commonly used alongside
	Rails. I eventually landed on RSpec and ended up being a core contributor for
	some time.

	Popular open source projects often have many issues reported against them, but
	the maintainers also frequently have difficulty triaging so many of them. In
	some of the cases, it’s very clear what’s going on and how to fix it. In other
	cases, the issue has been reported by someone lacking enough context to debug
	it effectively. I think this area is where new open source contributors can
	shine, especially if you like the thrill of the hunt: find issues where detail
	is lacking (e.g., no error message, no backtrace, no version) and ask the
	original reporter to provide some of these details. If there is enough detail
	to figure out how to reproduce the issue yourself, but there isn’t yet an
	automated test case, try writing one and making a pull request with just the
	new test. Even if you aren’t comfortable fixing the issue, an automated test
	case that’s failing (“red”) is a huge help and will likely motivate the core
	contributors to fix the issue sooner. And furthermore, the test doesn’t
	necessarily have to be the best test: just the fact that it demonstrates the
	issue in a way that everyone can reliably reproduce is good enough.

	By writing automated test cases for bugs, you’re also exploring the code base,
	getting familiar with the conventions, patterns, and existing design. Soon
	enough, it’s likely that you’ll have enough context to start adding new
	features or fixing bugs yourself. And that was probably the goal all along, but
	I think it can be too overwhelming to dive in all at once sometimes.

	Some folks also recommend writing documentation as a way to get started. I’m
	skeptical that this actually works in practice, at least for certain kinds of
	documentation, but certainly it is nice to look at projects with fresh eyes and
	improve the documentation in such a way that it would have made your life
	easier upon first using it.

	Hope this all makes sense. I’m happy to go into more detail. Good luck!