Skip to content

Instantly share code, notes, and snippets.

@alindeman

alindeman/gist:383177af82e7af2e27c0

Created May 25, 2014 17:40
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save alindeman/383177af82e7af2e27c0 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save alindeman/383177af82e7af2e27c0 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. alindeman revised this gist May 25, 2014. 1 changed file with 38 additions and 6 deletions.
    44 changes: 38 additions & 6 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -1,11 +1,43 @@
    > 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?
    > 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.
    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.
    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.
    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.
    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!
    Hope this all makes sense. I’m happy to go into more detail. Good luck!
  2. alindeman created this gist May 25, 2014.
    11 changes: 11 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,11 @@
    > 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!