Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Loading in …3
1 of 43

Projects, Community and Github: 4/10/2011



Download to read offline

Projects, Community and Github: CodeConf April 10, 2011

Related Books

Free with a 30 day trial from Scribd

See all

Projects, Community and Github: 4/10/2011

  1. 1. Andy Lester @petdance Projects, Community and Github
  2. 2. Who is Github for?
  3. 3. Developers, developers, developers, developers,
  4. 4. Github is not for end users.
  5. 5. Whoo! Exposure! Nat has 171,000 readers at
  6. 6. Somebody clicks the link and wants to download it, and what they're presented with is a dev- oriented home page.
  7. 7. The download link isn't very descriptive.
  8. 8. Github is for those who like to build from source.
  9. 9. Your users probably don't.
  10. 10. To the newcomer, the source tree is unimportant.
  11. 11. What's it do? What's it look like? Do I want to use it?
  12. 12. Make a project site. • Answer the newcomer's questions. • Aimed toward the end users. • Users who are not as ninja as you. • Make download + install incredibly obvious.
  13. 13. Make a project site.
  14. 14. Make a project site.
  15. 15. Get your own domain. • Not tied to github, in case things change. • $10/year = dirt-cheap investment • Which is easier to remember? • •
  16. 16. Visible, documented releases matter!
  17. 17. Releases matter!
  18. 18. Release for simplicity • Releases are an affirmation: "Yes, you can use this." • Single, verifiable tarball. • Nobody wants to run autoconf. • Users expect them.
  19. 19. Release for history and visibility • Lets others build on your work. • Make a milestone with history. • Maintain an accurate, human-written changelog of all releases. • A dump of commit messages is not a changelog!
  20. 20. Optimize for your users' sake, not your own.
  21. 21. The needs of the many outweigh the needs of the few, or the one.
  22. 22. About me
  23. 23. About @petdance • Perl guy: ack, prove, WWW::Mechanize • Programming for money since the 1980s • I sling PHP for B2B web apps for a (eww!) midsize corporation. • From the midwest, Chicago area • Diversity = good (c.f. @ginatrapani yesterday)
  24. 24. "Dad, if you don't get it, it's because I didn't do it."
  25. 25. Github projects have a low barrier to entry.
  26. 26. The good part: Anyone can do it.
  27. 27. The bad part: Anyone can do it.
  28. 28. Newbies expect their changes to be accepted.
  29. 29. "Can't you just...?"
  30. 30. Be gentle in your rejections. Brevity may be perceived as harsh.
  31. 31. That box is too small.
  32. 32. You want to accept changes from newbies if at all possible.
  33. 33. Don't reject patches just because of... • No tests • No documentation • Not following code standards • Those can all be fixed!
  34. 34. In this morning's mail...
  35. 35. I am happy to suggest use cases that I have found useful. What is the best way - to mailing list, on a wiki somewhere, email to you. Don't quite feel up to being more proactive. I am dyslexic and find writing stuff hard (and finishing of writing etc).
  36. 36. Make a project guide • Small chunks of the elephant • "TODO: Better error handling" is not helpful to the newbie. • Project direction • Coding standards • Workflow + branch strategy
  37. 37. Monitor your network
  38. 38. Thank you • Put yourself in the newbie's shoes. • Make a project home page outside Github. • Visible, documented releases matter. • Optimize for others, not yourself. • Use Github to encourage your community, not fend it off. • Thank you for listening and for Githubbing.