Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to 5 unspoken rules of contributing to open source software v2
Similar to 5 unspoken rules of contributing to open source software v2 (20)
Recently uploaded
Recently uploaded (20)
5 unspoken rules of contributing to open source software v2
- 1. 5 Unspoken Rules of Contributing to Open Source Software Michael Nelson cmljnelson cmljnelson.wordpress.com
- 2. Quick Survey Created a Pull Request? Submitted a Patch? Written code to work with WordPress? Participated in a Developer Chat? Use WordPress? Reportsed an issue?
- 3. Who am I?
- 4. My First Pull Request DisasterMy First Pull Request Disaster Customizing BuddyPress Docs
- 5. My First Pull Request Disaster Customizing BuddyPress Docs
- 6. My First Pull Request Disaster Customizing BuddyPress Docs
- 7. My First Pull Request Disaster Customizing BuddyPress Docs Video: You Can't Just Open a Pull Request and Run
- 8. My First Pull Request Disaster Post Mortem Pull Request Rejected Client Couldn't Update the Plugin
- 9. What's The Big Difference? Closed Source vs Open Source
- 10. What's The Big Difference? Closed Source vs Open Source Client Site BuddyPress Docs WordPressClient Site BuddyPress Docs WordPress Sites 1 8,000 276,000,000 Client Site BuddyPress Docs WordPress Sites 1 8,000 276,000,000 PHP Versions 5.5 5.2 - 7.1 5.2 – 7.1 Client Site BuddyPress Docs WordPress Sites 1 8,000 276,000,000 PHP Versions 5.5 5.2 - 7.1 5.2 – 7.1 Plugins ~10 52,000 52,000 Client Site BuddyPress Docs WordPress Sites 1 8,000 276,000,000 PHP Versions 5.5 5.2 - 7.1 5.2 – 7.1 Plugins ~10 52,000 52,000 Collaborators 0 40 500 Client Site BuddyPress Docs WordPress Sites 1 8,000 276,000,000 PHP Versions 5.5 5.2 - 7.1 5.2 – 7.1 Plugins ~10 52,000 52,000 Collaborators 0 40 500 Hackers Few A Few More A TON!
- 11. What's The Big Difference? Should You Take the Plunge into Open Source Software? ● Learn from World Class Professionals ● Support Software you Depend On ● Build Reputation
- 12. Rule 1: Justify Your Changes My Hand-Made Sweater Analogy
- 13. Rule 1: Justify Your Changes Pitfalls of Patches ● Bugs ● Incompatible with PHP, MySQL or webserver ● Conflicts with Plugins and Customizations ● Obstructs Other Features ● Performance ● Unused ● Complicates the UI ● Hard to Understand ● Maintenance Burden What could go wrong with a patch?
- 14. Rule 1: Justify Your Changes ● Describe the feature ● Your use-case What to Mention An Improved Pull Request ● Prior art ● Why this implementation
- 15. Rule 2: Be Willing to Discuss & Revise A More Typical Pull Request's Discussion ● JJJ involved since 2008, main BuddyPress developer ● 7 code revisions ● 11 months
- 16. Rule 2: Be Willing to Discuss & Revise An Improved Pull Request Discussion How would you respond?
- 17. Rule 3: Be Positive and Grateful We're Humans, not Laptops To have healthy open source communities, we need to learn how to be smart about our emotions... Your community is made of humans not laptops. Always communicate in a friendly way regardless of your current emotions. -Flavio Percoco, Red Hat
- 18. Rule 3: Be Positive and Grateful WordPress "Big Names" Always Keep It Positive
- 19. Rule 3: Be Positive and Grateful Show Your Gratitude for Free Software What is your favourite WordPress plugin? Have you done anything to support it?
- 20. Rule 4: Small Changes Are Easier Less Code Means Less Discussion Not all maintainers are keen on accepting massive change sets from new contributors. -Radek Pazdera
- 21. Rule 4: Small Changes Are Easier How to Keep Patches Small ● STOP if it's getting big! ● Make separate patches ● Focus the patch's purpose and avoid unnecessary improvements ● Don't Repeat Yourself
- 22. Rule 4: Small Changes Are Easier How to Achieve Big Features with Small Patches Snippet from my Original Pull Request
- 23. Rule 4: Small Changes Are Easier Alternative Change ...the rest in my own plugin How to Achieve Big Features with Small Patches
- 24. Rule 5: Companion Software is Easiest Make Your Own Project Instead of Complicating Someone Else's Should your favourite WordPress plugin be added to core?
- 25. Rule 5: Companion Software is Easiest The Benefits of Companion Software over Creating a Patch ● Bug free! ● Better for non-users ● If popular, justifies later merge ● Can be developed faster ● You get a plugin-owner badge!
- 26. Rule 5: Companion Software is Easiest WordPress' Companion Software Policies Core should provide features that 80% or more of end users will actually use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off... then we’ve blown it. https://wordpress.org/about/philosophy/#clean
- 27. Rule 5: Companion Software is Easiest What Will Your Own Plugin Make You?
- 28. Summary 1. Justify your Changes 2. Be Willing to Discuss and Revise 3. Be Gracious and Positive 4. Small Changes are Easier 5. Companion Software is the Easiest
- 29. How to Fulfill Your Destiny ● use open source software, and rate it ● suggest an improvements ● open pull requests ● create a plugin, put it on WordPress.org & GitHub ● participate in WordPress dev on Trac and Slack
- 30. Questions and Suggestions? Michael Nelson cmljnelson cmljnelson.wordpress.com
Editor's Notes
- * Welcome, I'm Mike. * Glad you fell for the click-bait title * purpose: help benefit from contributing to open source * my blog has a post, slides, link to my social media stuff * seeing how we're here in person, will make this a bit interactive. Learn from everyone
- Event Espresso $100,000, 000 annual ticket sales, running on 40,000 websites EventSmart is multisite site running EE, has 20,000 sites
- Story of my first pull request. * Where I was, * the company I worked for, * the client, * their needs.
- * BuddyPress Docs met needs * customized it quite easily * thought I'd share my improvement
- * Pull request was afterthought * no discussion ahead of time * no description of changes * no discussion.
- Video exagerates what went wrong. -Alt 2, Alt Enter, Ctr P Moral of the story
- * I was good at “closed source” (or at least private code, technically it was still open source) * But open source was a whole other ballgame
- Let's compare some facts
- * if open source is so much harder, why bother? - * let's look at the first rule I broke
- * no justification why Boone should take risk * because I thought my code was great, but it actually wasn't, and it had bugs
- Why do you need to justify it?
- How I would have done it differently
- Rule 3: be positive and grateful
- * Rule 4: reduce discussion by reducing code
- *Don't Rely on an existing project, help out with your own!