Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Maintaining a big open source project: lessons learned

Maintaining a big open source project: lessons learned

About a year ago, I started to maintain Devise - one of the most popular Ruby Gems available. I had no knowledge of the code and a little experience with open source from a side project I developed myself.

Obviously, this was a very challenging task and I made a lot of mistakes in the process. The good thing is I learned a lot too.

In this talk, I will share with you some of the lessons I learned that I think can be valuable not only for open source but for our day-to-day work too.

534f215d73d93dae9314db40d9746acd?s=128

Leonardo Tegon

May 02, 2019
Tweet

Transcript

  1. MAINTAINING A BIG OPEN SOURCE PROJECT: LESSONS LEARNED Leonardo Tegon

    - RailsConf 2019
  2. None
  3. None
  4. None
  5. None
  6. twitter.com/tegonl github.com/tegon

  7. None
  8. WE GET PAYED BY CLIENTS TO DELIVER PROJECTS

  9. SPARE TIME

  10. THE PROJECTS BECAME INACTIVE

  11. I WANTED TO HELP

  12. I DIDN'T KNOW WHERE TO START

  13. RUBYCONF BRASIL 2017

  14. The future of the Ruby community is brilliant but it

    depends on us — Rafael França
  15. None
  16. NOVEMBER 2017

  17. APRIL 2019

  18. None
  19. YOU'RE GOOD ENOUGH

  20. WHERE DO I START?

  21. ISSUE TRIAGE

  22. TRIAGE The process of examining problems in order to decide

    which ones are the most serious and must be dealt with first
  23. ISSUE TRIAGE Ensure that existing issues follow the recommendations from

    the project's contribution guide
  24. CONTRIBUTING.MD

  25. Include a title and a clear description, as much relevant

    information as possible and either a test case or a sample Rails app that replicates the issue — Devise's contribution guide
  26. IT'S HARD TO FIX BUGS WITHOUT ENOUGH INFORMATION

  27. TRY TO REPRODUCE THE ISSUE IN ISOLATION

  28. None
  29. None
  30. Avoid opening new issues to ask questions[...]. Please go through

    the project wiki, documentation and source code first, or try to ask your question on Stack Overflow. — Devise's contribution guide
  31. IT'S IMPORTANT TO ASK QUESTIONS

  32. THE ISSUES TRACKER MAY NOT BE THE BEST PLACE

  33. None
  34. IT'S HARD TO ASK QUESTIONS

  35. None
  36. ISSUE TRIAGE IS A GREAT WAY TO START

  37. https://words.steveklabnik.com/how-to-be-an-open-source-gardener

  38. 15 MINUTES PER DAY

  39. BUT I'M NOT A MAINTAINER!

  40. None
  41. None
  42. THERE ARE OTHER WAYS TO START

  43. REVIEW PULL REQUESTS

  44. ASK FOR TESTS

  45. TEST THE SOLUTION

  46. REPRODUCE AN ISSUE

  47. SHARE YOUR SOLUTION

  48. None
  49. DOCUMENTATION

  50. None
  51. #1. OPEN SOURCE IS MORE THAN CODE

  52. None
  53. REPRODUCE THE ISSUE

  54. REGRESSION

  55. https://thoughtbot.com/blog/git-bisect

  56. UNKNOWN ISSUES

  57. DIVE INTO THE CODE

  58. gem "pry"

  59. https://www.jackkinsella.ie/articles/debugging-rails-with-pry-debugger

  60. https://docs.gitlab.com/ee/development/pry_debugging.html

  61. https://medium.com/@urish/reading-your-frameworks-source-code-yes-you-can-do-it-2bdd8c9e947b

  62. YOU FOUND THE CODE THAT'S CAUSING THE ISSUE

  63. Once we read a piece of code for the very

    first time, we’re immersed in a long learning curve and a continuous cycle of questionings, doubts, and insights. — Rondy Sousa
  64. "WHAT WERE THEY THINKING?"

  65. "THIS MAKES NO SENSE"

  66. "THEY COULD HAVE DONE X INSTEAD"

  67. None
  68. None
  69. None
  70. None
  71. None
  72. None
  73. WE HAVE A LIMITED VISION OF THE WORLD

  74. None
  75. None
  76. ASK FOR ADVICE

  77. None
  78. #2. IT'S OK TO MAKE MISTAKES

  79. WHAT SHOULD I HAVE DONE?

  80. WHAT CAN I DO FROM NOW ON?

  81. None
  82. None
  83. #3. DOCUMENT THE DECISIONS

  84. None
  85. GIT COMMIT MESSAGES

  86. https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message

  87. https://chris.beams.io/posts/git-commit/

  88. None
  89. #4. CODE IS EXPENSIVE

  90. None
  91. #5. BE NICE

  92. None
  93. None
  94. RESPECT OTHER OPINIONS

  95. ASK QUESTIONS

  96. HAVE EMPATHY

  97. None
  98. None
  99. None
  100. https://signalvnoise.com/posts/3124-give-it-five-minutes

  101. GIVE IT A DAY

  102. None
  103. None
  104. GIVE IT A DAY

  105. None
  106. #6. TAKE CARE OF YOURSELF

  107. RELY ON AUTOMATED TOOLS

  108. None
  109. None
  110. None
  111. ASK FOR HELP

  112. COMMUNITY

  113. None
  114. None
  115. SHOW YOUR COMPANY WHY OSS IS IMPORTANT

  116. WHY OSS IS IMPORTANT •Blog posts •Talks •Motivation •Professional development

  117. OSS FRIDAYS

  118. PAID EXTRA HOURS

  119. None
  120. YOU DON'T NEED TO CODE TO HELP

  121. DOCUMENT THE DECISIONS

  122. BE NICE

  123. ASK FOR HELP

  124. None
  125. JOSÉ VALIM github.com/josevalim

  126. RAFAEL FRANÇA github.com/rafaelfranca

  127. FELIPE RENAN github.com/feliperenan

  128. THANK YOU! twitter.com/tegonl github.com/tegon

  129. REFERENCES •http://blog.plataformatec.com.br/2014/05/tips-for-keeping-your-open-source-software-issues- tracker-tidy/ •https://words.steveklabnik.com/how-to-be-an-open-source-gardener •http://blog.plataformatec.com.br/2018/06/the-anatomy-of-code-documentation/ •https://thoughtbot.com/blog/git-bisect •https://www.jackkinsella.ie/articles/debugging-rails-with-pry-debugger •https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message •https://chris.beams.io/posts/git-commit/

  130. IMAGE CREDITS •Helena Lopes: https://unsplash.com/photos/1m2LQEonm2A •Pawel Janiak: https://unsplash.com/photos/WtRuYJ2EPMA •Alejandro Escamilla:

    https://unsplash.com/photos/BbQLHCpVUqA •Sharon McCutcheon: https://unsplash.com/photos/8lnbXtxFGZw •Alexis Brown: https://unsplash.com/photos/-Xv7k95vOFA •Angelina Kichukova: https://unsplash.com/photos/AjaOjlImLjM •GIFs: https://giphy.com/brooklynninenine