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.

Transcript

1. ® Monday, 8 October 12
2. Bug Requests & Pull Reports Adam Rogers @rodreegez Monday, 8 October 12
3. Goals Monday, 8 October 12
4. Goals •Help us understand where bugs come from Monday, 8 October 12
5. Goals •Help us understand where bugs come from •Help us encourage people to contribute to our projects Monday, 8 October 12
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
7. Assumptions Monday, 8 October 12
8. Assumptions •Your code is open source and on GitHub Monday, 8 October 12
9. Assumptions •Your code is open source and on GitHub •A bug report is someone trying to help Monday, 8 October 12
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
11. Turning Bug Reports into Pull Requests Monday, 8 October 12
12. A bug report is a pull request without the code Monday, 8 October 12
13. Why do we get bug reports? Monday, 8 October 12
14. Why do we get bug reports? •Our code is broken Monday, 8 October 12
15. Why do we get bug reports? •Our code is broken •A feature was expected or is being requested Monday, 8 October 12
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
17. Reasons for not contributing Monday, 8 October 12
18. Reasons for not contributing •Knowing where to start can be hard Monday, 8 October 12
19. Reasons for not contributing •Knowing where to start can be hard •Understanding the domain can be difficult Monday, 8 October 12
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
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
22. What to do with broken code bugs? Monday, 8 October 12
23. What to do with broken code bugs? •Don’t fix them yourself! Monday, 8 October 12
24. What to do with broken code bugs? •Don’t fix them yourself! •Start a discussion Monday, 8 October 12
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
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
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
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
29. What to do with feature request bugs? Monday, 8 October 12
30. What to do with feature request bugs? •Don’t implement it! Monday, 8 October 12
31. What to do with feature request bugs? •Don’t implement it! •Start a discussion Monday, 8 October 12
32. What to do with feature request bugs? •Don’t implement it! •Start a discussion •What’s the best approach? Monday, 8 October 12
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
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
35. Feature requests we don’t want Monday, 8 October 12
36. Feature requests we don’t want •It will happen Monday, 8 October 12
37. Feature requests we don’t want •It will happen •It’s OK to say “no” Monday, 8 October 12
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
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
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
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
42. Preventing bug reports and encouraging pull requests Monday, 8 October 12
43. Documentation Monday, 8 October 12
44. Documentation •Readme Driven Development Monday, 8 October 12
45. Documentation •Readme Driven Development •In-line documentation Monday, 8 October 12
46. Documentation •Readme Driven Development •In-line documentation •Rdoc / YARD / TomDoc / Something Monday, 8 October 12
47. Documentation •Readme Driven Development •In-line documentation •Rdoc / YARD / TomDoc / Something •Private methods and internal classes too Monday, 8 October 12
48. Documentation •Readme Driven Development •In-line documentation •Rdoc / YARD / TomDoc / Something •Private methods and internal classes too •Wiki articles Monday, 8 October 12
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
50. Roadmap Monday, 8 October 12
51. Roadmap •Stand-alone or incorporated into the Readme Monday, 8 October 12
52. Roadmap •Stand-alone or incorporated into the Readme •Goals of the project Monday, 8 October 12
53. Roadmap •Stand-alone or incorporated into the Readme •Goals of the project •Where is the project going Monday, 8 October 12
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
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
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
57. Be predictable Monday, 8 October 12
58. Be predictable •`rake` runs the tests (there are tests, right?) Monday, 8 October 12
59. Be predictable •`rake` runs the tests (there are tests, right?) •Use Bundler Monday, 8 October 12
60. Be predictable •`rake` runs the tests (there are tests, right?) •Use Bundler •Dependency management Monday, 8 October 12
61. Be predictable •`rake` runs the tests (there are tests, right?) •Use Bundler •Dependency management •`bundle gem ...` Monday, 8 October 12
62. Be predictable •`rake` runs the tests (there are tests, right?) •Use Bundler •Dependency management •`bundle gem ...` •`rake release` Monday, 8 October 12
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
64. Doing less admin Monday, 8 October 12
65. Doing less admin •Delegate (but don’t abdicate) Monday, 8 October 12
66. Doing less admin •Delegate (but don’t abdicate) •Give commit access to people that have contributed Monday, 8 October 12
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
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
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
70. Summary Monday, 8 October 12
71. Summary •Bugs are either broken code, missing features or lacking documentation Monday, 8 October 12
72. Summary •Bugs are either broken code, missing features or lacking documentation •We shouldn’t fix them! Monday, 8 October 12
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
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
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
76. Thanks Adam Rogers @rodreegez Monday, 8 October 12