This document provides tips for using GitHub effectively to share projects and build developer communities. It recommends making a project site to provide essential information for new users, releasing projects regularly to affirm they can be used and allow others to build upon the work, and maintaining an open and helpful approach to contributions from newcomers to encourage participation and learning. The focus should be optimizing for users rather than just developers. GitHub projects have a low barrier to entry, so guidance and dividing work into approachable chunks is important to welcome new contributors.
Presentation on how to chat with PDF using ChatGPT code interpreter
Making Projects Welcoming for Newcomers
1. Andy Lester
@petdance
Projects,
Community
and Github
2. What we’ll cover
• Presenting your project to the world
• Managing the development process
• Side trip to diversity
• Your experiences
3. Why to stay
• Perspectives on community & you!
• Adorable Octocat art!
• Tips for patch management!
• Star Trek references!
• Release management!
• Sweaty Steve Ballmer!
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.
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/
29. Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.
30. Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.
• Nobody wants to run autoconf.
31. Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.
• Nobody wants to run autoconf.
• Users expect them.
34. Release for history
and visibility
• Lets others build on your work.
• Maintain an accurate, human-written
changelog of all releases.
35. 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!
41. 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
55. 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).
58. Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.
59. Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.
• Project direction
60. Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.
• Project direction
• Coding standards
61. 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
64. 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.
Editor's Notes
\n
\n
\n
\n
\n
\n
Nat has 171,000 readers at radar.oreilly.com\n
Somebody clicks the link and wants to download it, and what they're presented with is a dev-oriented home page.\n
The download link isn't very descriptive.\n
\n
\n
\n
\n
\n
\n
Somebody clicks the link and wants to download it, and what they're presented with is a dev-oriented home page.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
"Dad, if you don't get it, it's because I didn't do it."\n