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

Projects, Community and Github

Projects, Community and Github

Andy Lester

October 16, 2011
Tweet

More Decks by Andy Lester

Other Decks in Programming

Transcript

  1. Projects,
    Community
    and Github
    Andy Lester
    @petdance
    Sunday, October 16, 11

    View full-size slide

  2. What we’ll cover
    • Presenting your project to the world
    • Managing the development process
    • Side trip to diversity
    • Your experiences
    Sunday, October 16, 11

    View full-size slide

  3. Why to stay
    • Perspectives on community & you!
    • Adorable Octocat art!
    • Tips for patch management!
    • Star Trek references!
    • Release management!
    • Sweaty Steve Ballmer!
    Sunday, October 16, 11

    View full-size slide

  4. Who is Github for?
    Sunday, October 16, 11

    View full-size slide

  5. Developers,
    developers,
    developers,
    developers,
    Sunday, October 16, 11

    View full-size slide

  6. Github is not
    for end users.
    Sunday, October 16, 11

    View full-size slide

  7. Whoo! Exposure!
    Sunday, October 16, 11

    View full-size slide

  8. Sunday, October 16, 11

    View full-size slide

  9. Sunday, October 16, 11

    View full-size slide

  10. Github is for those
    who like to
    build from source.
    Sunday, October 16, 11

    View full-size slide

  11. Sunday, October 16, 11

    View full-size slide

  12. Sunday, October 16, 11

    View full-size slide

  13. Your users
    probably don't.
    Sunday, October 16, 11

    View full-size slide

  14. Sunday, October 16, 11

    View full-size slide

  15. To the newcomer,
    the source tree
    is unimportant.
    Sunday, October 16, 11

    View full-size slide

  16. To the newcomer,
    the source tree
    is unimportant.
    Sunday, October 16, 11

    View full-size slide

  17. Just because we’ve
    published code doesn’t
    mean we’re done.
    Sunday, October 16, 11

    View full-size slide

  18. What's it do?
    What's it look like?
    Do I want to use it?
    Sunday, October 16, 11

    View full-size slide

  19. That means:
    Screenshots and
    installation
    Sunday, October 16, 11

    View full-size slide

  20. Make a project site!
    Sunday, October 16, 11

    View full-size slide

  21. Make a project site.
    Sunday, October 16, 11

    View full-size slide

  22. Make a project site.
    Sunday, October 16, 11

    View full-size slide

  23. 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.
    • It can be on github, but not the default
    github project page.
    Sunday, October 16, 11

    View full-size slide

  24. Get your own domain.
    • Not tied to github, in case things change.
    • $10/year = dirt-cheap investment
    • Which is easier to remember?
    • http://github.com/petdance/ack
    • http://betterthangrep.com/
    Sunday, October 16, 11

    View full-size slide

  25. Visible, documented
    releases matter!
    Sunday, October 16, 11

    View full-size slide

  26. Releases matter!
    Sunday, October 16, 11

    View full-size slide

  27. Release for simplicity
    • Releases are an affirmation: "Yes, you can
    use this."
    • Single, verifiable tarball.
    • Nobody wants to run autoconf.
    • Users expect them.
    Sunday, October 16, 11

    View full-size slide

  28. Release for history
    and visibility
    • Lets others build on your work.
    • Maintain an accurate, human-written
    changelog of all releases.
    • A dump of commit messages is not a
    changelog!
    Sunday, October 16, 11

    View full-size slide

  29. Optimize for your
    users' sake,
    not your own.
    Sunday, October 16, 11

    View full-size slide

  30. The needs of the many
    outweigh the needs of
    the few, or the one.
    Sunday, October 16, 11

    View full-size slide

  31. The needs of the users
    outweigh the needs of
    the project team.
    Sunday, October 16, 11

    View full-size slide

  32. Sunday, October 16, 11

    View full-size slide

  33. About me
    Sunday, October 16, 11

    View full-size slide

  34. About @petdance
    • Perl guy: ack, prove, WWW::Mechanize
    • Programming for money since the 1980s
    • I sling PHP for B2B web apps for a midsize
    corporation.
    • From the midwest, Chicago area
    Sunday, October 16, 11

    View full-size slide

  35. Sunday, October 16, 11

    View full-size slide

  36. A little bit about ack
    Sunday, October 16, 11

    View full-size slide

  37. Github projects have a
    low barrier to entry.
    Sunday, October 16, 11

    View full-size slide

  38. The good part:
    Anyone can do it.
    Sunday, October 16, 11

    View full-size slide

  39. The bad part:
    Anyone can do it.
    Sunday, October 16, 11

    View full-size slide

  40. Newbies expect their
    changes to be accepted.
    Sunday, October 16, 11

    View full-size slide

  41. "Can't you just...?"
    Sunday, October 16, 11

    View full-size slide

  42. Be gentle in your
    rejections.
    Brevity may be
    perceived as harsh.
    Sunday, October 16, 11

    View full-size slide

  43. That box is too small.
    Sunday, October 16, 11

    View full-size slide

  44. You want to accept
    changes from newbies if
    at all possible.
    Sunday, October 16, 11

    View full-size slide

  45. Don't reject patches
    just because of...
    • No tests
    • No documentation
    • Not following code standards
    • Those can all be fixed!
    Sunday, October 16, 11

    View full-size slide

  46. The other day I got this
    in the mail...
    Sunday, October 16, 11

    View full-size slide

  47. Sunday, October 16, 11

    View full-size slide

  48. 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).
    Sunday, October 16, 11

    View full-size slide

  49. 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
    Sunday, October 16, 11

    View full-size slide

  50. Monitor your network
    Sunday, October 16, 11

    View full-size slide

  51. Sunday, October 16, 11

    View full-size slide

  52. 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.
    Sunday, October 16, 11

    View full-size slide