Bug Requests & Pull Reports 2.0

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