Published on

Presentation for the Dutch PHP Conference on the various ways to contribute to Open Source Software, how to develop karma in a community, and some rules to make your interactions with other developers more fruitful.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Contribute! Matthew Weier O'Phinney Project Lead, Zend Framework
  2. 2. Who are you? <ul><li>Lead an open source project?
  3. 3. Contributed code to an OSS project?
  4. 4. Written or translated documentation for an OSS project?
  5. 5. Answered questions on an OSS mailing list, forum, or IRC channel?
  6. 6. Blogged solutions or tutorials regarding an OSS project? </li></ul>
  7. 7. Why contribute? <ul><li>You've identified bugs using an OSS project and want them fixed upstream
  8. 8. You've created a feature you think fits an OSS project's goals
  9. 9. An OSS project has made your life easier, and you want to contribute back
  10. 10. Fame, fortune, glory!
  11. 11. It's fun! </li></ul>
  12. 12. You need karma
  13. 13. <ul><li>OSS is a meritocracy
  14. 14. Contributions earn you karma </li><ul><li>Well, good contributions... </li></ul></ul>
  15. 15. The Golden Rule...
  16. 16. Communication is the key to any good OSS project
  17. 17. Communication Channels <ul><li>Mailing lists
  18. 18. IRC
  19. 19. Forums
  20. 20. Twitter
  21. 21. Issue trackers
  22. 22. Wikis
  23. 23. Blogs </li></ul>
  24. 24. Mailing lists and forums <ul><li>Ask questions </li><ul><li>Don't be vague; the more detail the better
  25. 25. Don't abuse the list; try things first
  26. 26. Don't abuse those who take the time to help you </li></ul><li>Answer questions </li><ul><li>Don't denigrate those asking questions
  27. 27. Blog questions you answer often </li></ul><li>BE NICE! </li></ul>
  28. 28. IRC <ul><li>Freenode, Efnet, etc
  29. 29. Most projects have channels
  30. 30. Don't ask questions on channels marked for developers/contributors only
  31. 31. Don't paste large amounts of code in the channel; use pastebins
  32. 32. Don't be pushy </li></ul>
  33. 33. Twitter <ul><li>Ask questions </li><ul><li>Don't do it often
  34. 34. Don't expect an answer
  35. 35. Keep it simple </li></ul><li>Answer questions </li><ul><li>Don't batch responses
  36. 36. Don't be afraid to link to other sources </li></ul><li>Be nice! </li></ul>
  37. 37. Issue Reporting <ul><li>The secret to good reporting: </li><ul><li>Document your expected results
  38. 38. Document your actual results
  39. 39. Provide the minimum code necessary to reproduce the results you report </li></ul></ul>
  40. 40. Issue Reporting <ul><li>Always pull from the active development branch before reporting </li><ul><li>Verify the bug still exists </li></ul><li>Check with developers </li><ul><li>Verify that the issue isn't actually by design or a misunderstanding on your part </li></ul><li>If you reproduce case is greater than 20 statements... see if you can reproduce it in less </li></ul>
  41. 41. Creating a patch <ul><li>Always create the patch from the root of the branch </li><ul><li>Typically from your checkout of trunk or the release branch you are using </li></ul><li>Use the diff tool from the VCS system used by the project </li><ul><li>svn diff > /tmp/my_patch.diff
  42. 42. git log -p <r>..<r> > /tmp/my_patch.diff </li></ul></ul>
  43. 43. Testing a patch <ul><li>Help out by testing patches uploaded by others
  44. 44. Typically from the branch root: </li><ul><li>patch -p0 < my_patch.diff </li></ul></ul>
  45. 45. Write Documentation <ul><li>Blog – write tutorials, or blog solutions to problems you've encountered.
  46. 46. Wiki – if the project uses a wiki for documentation, write documentation directly.
  47. 47. Learn Docbook – many large projects use it. Just learn it.
  48. 48. Documentation isn't in your language? Translate it! </li></ul>
  49. 49. Other activities <ul><li>Join your local user group </li><ul><li>Share your knowledge
  50. 50. Learn from others
  51. 51. Collaborate
  52. 52. Bug hunts / test fest </li></ul><li>Attend or speak at conferences </li><ul><li>Travel and learn from others
  53. 53. Evangelize the projects you use </li></ul></ul>
  54. 54. What are you waiting for? Feedback: