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!

4.
Who is Github for?

5.
Developers,
developers,
developers,
developers,

6.
Github is not
for end users.

7.
Whoo! Exposure!

8.
Github is for those
who like to
build from source.

9.
Your users
probably don't.

10.
To the newcomer,
the source tree
is unimportant.

11.
To the newcomer,
the source tree
is unimportant.

12.
Just because we’ve
published code doesn’t
mean we’re done.

13.
What's it do?
What's it look like?
Do I want to use it?

14.
That means:
Screenshots and
installation

15.
Make a project site!

16.
Make a project site.

17.
Make a project site.

18.
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.

19.
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/

20.
Visible, documented
releases matter!

21.
Releases matter!

22.
Release for simplicity

23.
Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."

24.
Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.

25.
Release for simplicity
• Releases are an affirmation: "Yes, you can
use this."
• Single, verifiable tarball.
• Nobody wants to run autoconf.

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

27.
Release for history
and visibility

28.
Release for history
and visibility
• Lets others build on your work.

29.
Release for history
and visibility
• Lets others build on your work.
• Maintain an accurate, human-written
changelog of all releases.

30.
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!

31.
Optimize for your
users' sake,
not your own.

32.
The needs of the many
outweigh the needs of
the few, or the one.

33.
The needs of the users
outweigh the needs of
the project team.

34.
About me

35.
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

36.
A little bit about ack

37.
Github projects have a
low barrier to entry.

38.
The good part:
Anyone can do it.

39.
The bad part:
Anyone can do it.

40.
Newbies expect their
changes to be accepted.

41.
"Can't you just...?"

42.
Be gentle in your
rejections.
Brevity may be
perceived as harsh.

43.
That box is too small.

44.
You want to accept
changes from newbies if
at all possible.

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

46.
The other day I got this
in the mail...

47.
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).

48.
Make a project guide

49.
Make a project guide
• Small chunks of the elephant

50.
Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.

51.
Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.
• Project direction

52.
Make a project guide
• Small chunks of the elephant
• "TODO: Better error handling" is not
helpful to the newbie.
• Project direction
• Coding standards

53.
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

54.
Monitor your network

55.
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.