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

Bug Requests & Pull Reports 2.0

rodreegez
October 08, 2012

Bug Requests & Pull Reports 2.0

Given at Arrrrcamp 2012, this version of the talk focuses less on Powder and more on the wider lessons learned and the implications of them.

rodreegez

October 08, 2012
Tweet

More Decks by rodreegez

Other Decks in Programming

Transcript

  1. ®
    Monday, 8 October 12

    View Slide

  2. Bug Requests & Pull Reports
    Adam Rogers
    @rodreegez
    Monday, 8 October 12

    View Slide

  3. Goals
    Monday, 8 October 12

    View Slide

  4. Goals
    •Help us understand where bugs come from
    Monday, 8 October 12

    View Slide

  5. Goals
    •Help us understand where bugs come from
    •Help us encourage people to contribute to our
    projects
    Monday, 8 October 12

    View Slide

  6. Goals
    •Help us understand where bugs come from
    •Help us encourage people to contribute to our
    projects
    •Help us spend less time doing admin
    Monday, 8 October 12

    View Slide

  7. Assumptions
    Monday, 8 October 12

    View Slide

  8. Assumptions
    •Your code is open source and on GitHub
    Monday, 8 October 12

    View Slide

  9. Assumptions
    •Your code is open source and on GitHub
    •A bug report is someone trying to help
    Monday, 8 October 12

    View Slide

  10. Assumptions
    •Your code is open source and on GitHub
    •A bug report is someone trying to help
    •Bugs are reported by developers
    Monday, 8 October 12

    View Slide

  11. Turning Bug Reports into
    Pull Requests
    Monday, 8 October 12

    View Slide

  12. A bug report is a pull request
    without the code
    Monday, 8 October 12

    View Slide

  13. Why do we get bug reports?
    Monday, 8 October 12

    View Slide

  14. Why do we get bug reports?
    •Our code is broken
    Monday, 8 October 12

    View Slide

  15. Why do we get bug reports?
    •Our code is broken
    •A feature was expected or is being requested
    Monday, 8 October 12

    View Slide

  16. Why do we get bug reports?
    •Our code is broken
    •A feature was expected or is being requested
    •Someone is looking for help
    Monday, 8 October 12

    View Slide

  17. Reasons for not contributing
    Monday, 8 October 12

    View Slide

  18. Reasons for not contributing
    •Knowing where to start can be hard
    Monday, 8 October 12

    View Slide

  19. Reasons for not contributing
    •Knowing where to start can be hard
    •Understanding the domain can be difficult
    Monday, 8 October 12

    View Slide

  20. Reasons for not contributing
    •Knowing where to start can be hard
    •Understanding the domain can be difficult
    •Setting up the project may take too much time
    Monday, 8 October 12

    View Slide

  21. Reasons for not contributing
    •Knowing where to start can be hard
    •Understanding the domain can be difficult
    •Setting up the project may take too much time
    •Your code’s great, and Imma let you finish...
    Monday, 8 October 12

    View Slide

  22. What to do with broken code
    bugs?
    Monday, 8 October 12

    View Slide

  23. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    Monday, 8 October 12

    View Slide

  24. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    •Start a discussion
    Monday, 8 October 12

    View Slide

  25. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    •Start a discussion
    •Ask the reporter where they think the issue is
    Monday, 8 October 12

    View Slide

  26. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    •Start a discussion
    •Ask the reporter where they think the issue is
    •Call out to friends
    Monday, 8 October 12

    View Slide

  27. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    •Start a discussion
    •Ask the reporter where they think the issue is
    •Call out to friends
    •Tell them your thoughts on the issue
    Monday, 8 October 12

    View Slide

  28. What to do with broken code
    bugs?
    •Don’t fix them yourself!
    •Start a discussion
    •Ask the reporter where they think the issue is
    •Call out to friends
    •Tell them your thoughts on the issue
    •Be encouraging
    Monday, 8 October 12

    View Slide

  29. What to do with feature request
    bugs?
    Monday, 8 October 12

    View Slide

  30. What to do with feature request
    bugs?
    •Don’t implement it!
    Monday, 8 October 12

    View Slide

  31. What to do with feature request
    bugs?
    •Don’t implement it!
    •Start a discussion
    Monday, 8 October 12

    View Slide

  32. What to do with feature request
    bugs?
    •Don’t implement it!
    •Start a discussion
    •What’s the best approach?
    Monday, 8 October 12

    View Slide

  33. What to do with feature request
    bugs?
    •Don’t implement it!
    •Start a discussion
    •What’s the best approach?
    •How does this new feature impact the wider codebase?
    Monday, 8 October 12

    View Slide

  34. What to do with feature request
    bugs?
    •Don’t implement it!
    •Start a discussion
    •What’s the best approach?
    •How does this new feature impact the wider codebase?
    •Do we even want to support this?
    Monday, 8 October 12

    View Slide

  35. Feature requests we don’t want
    Monday, 8 October 12

    View Slide

  36. Feature requests we don’t want
    •It will happen
    Monday, 8 October 12

    View Slide

  37. Feature requests we don’t want
    •It will happen
    •It’s OK to say “no”
    Monday, 8 October 12

    View Slide

  38. Feature requests we don’t want
    •It will happen
    •It’s OK to say “no”
    •Don’t be a dick
    Monday, 8 October 12

    View Slide

  39. Feature requests we don’t want
    •It will happen
    •It’s OK to say “no”
    •Don’t be a dick
    •Help figure out how to solve the reporter’s issue
    Monday, 8 October 12

    View Slide

  40. Feature requests we don’t want
    •It will happen
    •It’s OK to say “no”
    •Don’t be a dick
    •Help figure out how to solve the reporter’s issue
    •Plugins, dependencies, API’s?
    Monday, 8 October 12

    View Slide

  41. Feature requests we don’t want
    •It will happen
    •It’s OK to say “no”
    •Don’t be a dick
    •Help figure out how to solve the reporter’s issue
    •Plugins, dependencies, API’s?
    •Ultimately, OSS can be forked, and that’s OK too
    Monday, 8 October 12

    View Slide

  42. Preventing bug reports and
    encouraging pull requests
    Monday, 8 October 12

    View Slide

  43. Documentation
    Monday, 8 October 12

    View Slide

  44. Documentation
    •Readme Driven Development
    Monday, 8 October 12

    View Slide

  45. Documentation
    •Readme Driven Development
    •In-line documentation
    Monday, 8 October 12

    View Slide

  46. Documentation
    •Readme Driven Development
    •In-line documentation
    •Rdoc / YARD / TomDoc / Something
    Monday, 8 October 12

    View Slide

  47. Documentation
    •Readme Driven Development
    •In-line documentation
    •Rdoc / YARD / TomDoc / Something
    •Private methods and internal classes too
    Monday, 8 October 12

    View Slide

  48. Documentation
    •Readme Driven Development
    •In-line documentation
    •Rdoc / YARD / TomDoc / Something
    •Private methods and internal classes too
    •Wiki articles
    Monday, 8 October 12

    View Slide

  49. Documentation
    •Readme Driven Development
    •In-line documentation
    •Rdoc / YARD / TomDoc / Something
    •Private methods and internal classes too
    •Wiki articles
    •Man pages (gem man)
    Monday, 8 October 12

    View Slide

  50. Roadmap
    Monday, 8 October 12

    View Slide

  51. Roadmap
    •Stand-alone or incorporated into the Readme
    Monday, 8 October 12

    View Slide

  52. Roadmap
    •Stand-alone or incorporated into the Readme
    •Goals of the project
    Monday, 8 October 12

    View Slide

  53. Roadmap
    •Stand-alone or incorporated into the Readme
    •Goals of the project
    •Where is the project going
    Monday, 8 October 12

    View Slide

  54. Roadmap
    •Stand-alone or incorporated into the Readme
    •Goals of the project
    •Where is the project going
    •Broad-strokes plan
    Monday, 8 October 12

    View Slide

  55. Roadmap
    •Stand-alone or incorporated into the Readme
    •Goals of the project
    •Where is the project going
    •Broad-strokes plan
    •Features we want
    Monday, 8 October 12

    View Slide

  56. Roadmap
    •Stand-alone or incorporated into the Readme
    •Goals of the project
    •Where is the project going
    •Broad-strokes plan
    •Features we want
    •Features we don’t want
    Monday, 8 October 12

    View Slide

  57. Be predictable
    Monday, 8 October 12

    View Slide

  58. Be predictable
    •`rake` runs the tests (there are tests, right?)
    Monday, 8 October 12

    View Slide

  59. Be predictable
    •`rake` runs the tests (there are tests, right?)
    •Use Bundler
    Monday, 8 October 12

    View Slide

  60. Be predictable
    •`rake` runs the tests (there are tests, right?)
    •Use Bundler
    •Dependency management
    Monday, 8 October 12

    View Slide

  61. Be predictable
    •`rake` runs the tests (there are tests, right?)
    •Use Bundler
    •Dependency management
    •`bundle gem ...`
    Monday, 8 October 12

    View Slide

  62. Be predictable
    •`rake` runs the tests (there are tests, right?)
    •Use Bundler
    •Dependency management
    •`bundle gem ...`
    •`rake release`
    Monday, 8 October 12

    View Slide

  63. Be predictable
    •`rake` runs the tests (there are tests, right?)
    •Use Bundler
    •Dependency management
    •`bundle gem ...`
    •`rake release`
    •Keep the master branch releasable
    Monday, 8 October 12

    View Slide

  64. Doing less admin
    Monday, 8 October 12

    View Slide

  65. Doing less admin
    •Delegate (but don’t abdicate)
    Monday, 8 October 12

    View Slide

  66. Doing less admin
    •Delegate (but don’t abdicate)
    •Give commit access to people that have contributed
    Monday, 8 October 12

    View Slide

  67. Doing less admin
    •Delegate (but don’t abdicate)
    •Give commit access to people that have contributed
    •Your Mileage May Vary
    Monday, 8 October 12

    View Slide

  68. Doing less admin
    •Delegate (but don’t abdicate)
    •Give commit access to people that have contributed
    •Your Mileage May Vary
    •All good OSS projects have leadership and an
    awesome team.
    Monday, 8 October 12

    View Slide

  69. Doing less admin
    •Delegate (but don’t abdicate)
    •Give commit access to people that have contributed
    •Your Mileage May Vary
    •All good OSS projects have leadership and an
    awesome team.
    •Be that leader, build that team.
    Monday, 8 October 12

    View Slide

  70. Summary
    Monday, 8 October 12

    View Slide

  71. Summary
    •Bugs are either broken code, missing features or
    lacking documentation
    Monday, 8 October 12

    View Slide

  72. Summary
    •Bugs are either broken code, missing features or
    lacking documentation
    •We shouldn’t fix them!
    Monday, 8 October 12

    View Slide

  73. Summary
    •Bugs are either broken code, missing features or
    lacking documentation
    •We shouldn’t fix them!
    •We should instigate discussion
    Monday, 8 October 12

    View Slide

  74. Summary
    •Bugs are either broken code, missing features or
    lacking documentation
    •We shouldn’t fix them!
    •We should instigate discussion
    •We should maintain good documentation
    Monday, 8 October 12

    View Slide

  75. Summary
    •Bugs are either broken code, missing features or
    lacking documentation
    •We shouldn’t fix them!
    •We should instigate discussion
    •We should maintain good documentation
    •We should welcome and encourage contributions
    Monday, 8 October 12

    View Slide

  76. Thanks
    Adam Rogers
    @rodreegez
    Monday, 8 October 12

    View Slide