Personal blog written from scratch using Node.js, Bootstrap, and MySQL. https://jrtechs.net
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

70 lines
3.2 KiB

  1. The main goal is this post is to document a bugfix I made for RIT's
  2. [HFOSS](http://hfoss.rocfoss.org/) class. I feel that documenting the
  3. process of making a bugfix will help other people looking to
  4. contribute towards open source projects.
  5. # Identify the Bug
  6. The first step in a bug fix quest is to find a bug. If you happen to
  7. find a bug, it is important that you check current issues to make sure
  8. that that bug has not already been reported. If you have no clue
  9. where to begin, I found it helpful to look for issues tagged as help
  10. wanted in a repository.
  11. The other day I was notified about an issue opened on the RITlug (RIT
  12. Linux Users Group) website. I got this notification via Github. If you
  13. are active on a project, it is useful to be subscribed to their
  14. mailing list or issue tracker so you get alerted when an issue that you
  15. can work on comes up. I really like Github because it gives you a lot
  16. of freedom in what issues/users/projects you are notified about.
  17. [https://github.com/RITlug/ritlug.github.io/issues/263](https://github.com/RITlug/ritlug.github.io/issues/263)
  18. Since I had familiarity with web development and was flagged as help
  19. wanted, I decided to fix this issue.
  20. # Communicate with Project
  21. After you find a bug it is best to communicate with the project that
  22. you wish to fix this bug. In my case, I did this by leaving a comment
  23. on the issue and assigning the issue to myself. This is very helpful
  24. because on very active projects if you don't assign yourself the
  25. issue, there is a chance that two or more people would try to fix the
  26. issue at the same time. Making yourself know for solving the issue is
  27. also enables you to initiate a dialog with other people in the project
  28. interested in this issue. This is also a great time to solicit
  29. feedback about how exactly the issue should get resolved.
  30. # Fix the Bug
  31. Just do it! For the bug that I found I just had to modify some HTML
  32. and validate that it worked by running the
  33. [Jeckyll](https://jekyllrb.com/) project. When working on bug fixes or
  34. enhancements in general it is best to include documentation for any
  35. changes that you make and work on a separate branch.
  36. # Submit Patch and Make Additional Changes
  37. The last thing you need to do is submit your code for a code review so
  38. you can get your changes merged into the project. To do this on Github
  39. you simply file a pull request. When creating a pull request it is
  40. helpful to link to the original issue and provide a brief description
  41. of what changes were made. Pull requests can be a place where a lot of
  42. back and forth communication happens. Code reviews are places for you
  43. to fix mistakes, resolve, misunderstandings and improve your code in
  44. general. If you are reviewing code it is essential to give
  45. constructive feedback so people can effectively work on the project.
  46. The pull request with the changes I made for the RITlug website could
  47. be found here:
  48. [https://github.com/RITlug/ritlug.github.io/pull/266](https://github.com/RITlug/ritlug.github.io/pull/266)
  49. # Do it again!
  50. Once you get in the groove of contributing to open source project it
  51. is enthralling. Like anything else, practice makes perfect. One thing
  52. to note is that not every open source community is the same, some will
  53. be easier to get into than others for contributing.