15. 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.
18. 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/
21. Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.
• Nobody wants to run autoconf.
• Users expect them.
22. 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!
26. 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)
27. "Dad, if you don't get it, it's because I didn't do it."
39. 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).
40. 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
43. 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.