alindeman/gist:383177af82e7af2e27c0

## 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!