Projects, Community and Github

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Who is Github for? Sunday, October 16, 11

Slide 5

Slide 5 text

Developers, developers, developers, developers, Sunday, October 16, 11

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Whoo! Exposure! Sunday, October 16, 11

Slide 8

Slide 8 text

Sunday, October 16, 11

Slide 9

Slide 9 text

Sunday, October 16, 11

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Sunday, October 16, 11

Slide 12

Slide 12 text

Sunday, October 16, 11

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Sunday, October 16, 11

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Make a project site! Sunday, October 16, 11

Slide 21

Slide 21 text

Make a project site. Sunday, October 16, 11

Slide 22

Slide 22 text

Make a project site. Sunday, October 16, 11

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Releases matter! Sunday, October 16, 11

Slide 27

Slide 27 text

Release for simplicity • Releases are an afﬁrmation: "Yes, you can use this." • Single, veriﬁable tarball. • Nobody wants to run autoconf. • Users expect them. Sunday, October 16, 11

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Sunday, October 16, 11

Slide 33

Slide 33 text

About me Sunday, October 16, 11

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Sunday, October 16, 11

Slide 36

Slide 36 text

A little bit about ack Sunday, October 16, 11

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Sunday, October 16, 11

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Make a project guide • Small chunks of the elephant • "TODO: Better error handling" is not helpful to the newbie. • Project direction • Coding standards • Workﬂow + branch strategy Sunday, October 16, 11

Slide 50

Slide 50 text

Monitor your network Sunday, October 16, 11

Slide 51

Slide 51 text

Sunday, October 16, 11

Slide 52

Slide 52 text

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