Projects, Community and Github

Transcript

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

   11

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

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

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

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

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

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

8. Sunday, October 16, 11

9. Sunday, October 16, 11

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

    Sunday, October 16, 11

11. Sunday, October 16, 11

12. Sunday, October 16, 11

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

14. Sunday, October 16, 11

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

    16, 11

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

    16, 11

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

    October 16, 11

18. What's it do? What's it look like? Do I want

    to use it? Sunday, October 16, 11

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

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

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

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

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

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

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

26. Releases matter! Sunday, October 16, 11

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

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

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

    16, 11

30. The needs of the many outweigh the needs of the

    few, or the one. Sunday, October 16, 11

31. The needs of the users outweigh the needs of the

    project team. Sunday, October 16, 11

32. Sunday, October 16, 11

33. About me Sunday, October 16, 11

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

35. Sunday, October 16, 11

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

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

    16, 11

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

    11

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

    11

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

    11

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

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

    harsh. Sunday, October 16, 11

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

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

    possible. Sunday, October 16, 11

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

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

    October 16, 11

47. Sunday, October 16, 11

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

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

50. Monitor your network Sunday, October 16, 11

51. Sunday, October 16, 11

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