![Rule 3: Be Positive and Grateful
The Value of Keeping It Positive
To have happy and healthy open source
communities, we need to learn how to be
smart about our emotions...
[Y]our community is made [of] humans
not laptops. So assume good faith or
better, and always communicate in a
friendly way regardless of what your
current emotions are...
https://opensource.com/article/16/11/communities-emotions-matter
-Flavio Percoco, Red Hat](https://image.slidesharecdn.com/5unspokerulesofcontributingtoopensourcesoftware-171021140433/85/5-unspoke-rules-of-contributing-to-open-source-software-18-320.jpg)
![Rule 3: Be Positive and Grateful
The Value of Keeping It Positive
[You] can’t go to the outside of my house
and spray-paint on my walls.
When you come into my house on the
web, you can read all my posts, and you
can write any comments. ..but you don’t
get to decide whether I keep your
comment and I make it public. I’m
ruthless about taking down your trolling
comments and getting rid of them on my
site.
https://austinlchurch.com/how-to-become-a-blogger-tips-on-
starting-a-blog-from-chris-lema/
-Chris Lema](https://image.slidesharecdn.com/5unspokerulesofcontributingtoopensourcesoftware-171021140433/85/5-unspoke-rules-of-contributing-to-open-source-software-19-320.jpg)
5 unspoke rules of contributing to open source software
- 1. 5 Unspoken Rules of Contributing to Open Source Software Michael Nelson
- 2. Quick Survey Created a Pull Request? Submitted a Patch? Written code to work with WordPress? Participated in a Developer Chat? Use WordPress?
- 3. Who am I?
- 4. My First Pull Request Disaster Customizing BuddyPress Docs My 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 I thought my Pull Request was this... ...it was actually this... ...and it contained this.
- 13. Rule 1: Justify Your Changes Pitfalls of Patches ● Bugs ● Incompatible with PHP, MySQL or webserver ● Conflicts with Plugins and Customizations ● Obstructs Other Planned Features ● Performance ● Unused ● Complicates the UI ● Maintenance Burden What could go wrong with a patch?
- 14. Rule 1: Justify Your Changes ● Describe the feature ● Your use-case ● Other use-cases ● Prior art ● Why this implementation What to Mention An Improved Pull Request
- 15. Rule 2: Be Willing to Discuss & Revise What Does Silence Mean? ● "Uh- could you repeat that? I wasn't listening" ● "I understand so little of what you just said, I don't know what to even ask" ● Nobody's here ● "I'm thinking or checking with others" ● "I thought someone else would reply" ● "I'm too busy right now" ● "I'm really tired of this and want it to just end"
- 16. 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
- 17. Rule 2: Be Willing to Discuss & Revise An Improved Pull Request Discussion How would you respond?
- 18. Rule 3: Be Positive and Grateful The Value of Keeping It Positive To have happy and healthy open source communities, we need to learn how to be smart about our emotions... [Y]our community is made [of] humans not laptops. So assume good faith or better, and always communicate in a friendly way regardless of what your current emotions are... https://opensource.com/article/16/11/communities-emotions-matter -Flavio Percoco, Red Hat
- 19. Rule 3: Be Positive and Grateful The Value of Keeping It Positive [You] can’t go to the outside of my house and spray-paint on my walls. When you come into my house on the web, you can read all my posts, and you can write any comments. ..but you don’t get to decide whether I keep your comment and I make it public. I’m ruthless about taking down your trolling comments and getting rid of them on my site. https://austinlchurch.com/how-to-become-a-blogger-tips-on- starting-a-blog-from-chris-lema/ -Chris Lema
- 20. Rule 3: Be Positive and Grateful WordPress "Big Names" Always Keep It Positive
- 21. 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?
- 22. Rule 4: Small Changes Are Easier Less Code Means Less Discussion Not all maintainers are keen on accepting massive change sets from new contributors. https://opensource.com/life/15/2/developers-guide-getting-involved-open-source -Radek Pazdera
- 23. 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
- 24. Rule 4: Small Changes Are Easier How to Achieve Big Features with Small Patches Snippet from my Original Pull Request
- 25. Rule 4: Small Changes Are Easier How to Achieve Big Features with Small Patches Alternative Change ...and left all the complexity in my own plugin
- 26. 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?
- 27. 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 ● You get a plugin-owner badge!
- 28. Rule 5: Companion Software is Easiest WordPress' Companion Software Policies The rule of thumb is that the 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
- 29. Rule 5: Companion Software is Easiest Separate Code is Faster Code ● Lower stakes ● Fewer collaborators ● Less complexity ● Breaking Backward Compatibility Possible
- 30. 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
- 31. How to Fulfill Your Destiny ● use open source software, and rate it ● when you notice a deficiency, suggest an improvement ● become familiar with making pull requests on GitHub ● open a pull request ● create companion software and put it on GitHub ● participate in a project's discussion
Editor's Notes
- #2: Welcome everyone to "Five Unspoken Rules of Contributing to Open Source Software". This presentation will be focusing on contributing code to open source projects like WordPress and its plugins and themes, although it's actually not too technical. This is primarily directed at developers proficient at writing code on their own or with a team, and want to improve at contributing to open source.
- #3: Because this is a presentation and not a video, this will be a little more interactive. First off, I'm interested to know where we're at. By show of hands, how many of you use WordPress? (Probably everyone) How many of you feel fairly comfortable writing PHP or Javascript code for you or your clients' projects? How many of you have opened a pull request on GitHub or otherwise submitted code to an open source project? (For those who are not familiar with it, GitHub is the go-to place nearly all open source projects are kept.) How many of you have submitted code for WordPress core on Trac? (For those not aware, the website where features and most bugs in WordPress itself, not plugins or themes that work with it, is called Trac.)
- #4: I'm a developer of the event registration plugin Event Espresso, one of about 10 working on it and it's related plugins that we call "add-ons". I've been doing this for five years. It's running over 40,000 websites and processing over $100,000 in ticket sales per year. Mind you, we actually see very little of that money, because we only charge a flat annual fee for support and automatic downloads, not a percentage of their revenue like most others do. Actually, I don't really understand how we make any money. For about the last 4 years, Event Espresso's code has been freely available on GitHub, so users can actually download it for free. And about 6 months ago we even put most of our add-ons on GitHub, also totally free. So I don't understand how we make any money- good thing the financials isn't my area of expertise. My areas of focus are payment gateway integrations (like PayPal, Stripe, etc), database integration, and REST API integration, and a few others. I'm one of the developers who respond to pull requests on GitHub. In working on our plugin, I sometimes contribute code to WordPress core - usually just when there is a specific feature we need or a bug we uncovered. So I'm quite involved in WordPress' open source world and have some experience with it, but certainly not as much as others, but more than I had before I started with Event Espresso.
- #5: Story of my first pull request. The situation, motivation, and results.
- #6: Story of my first pull request. The situation, motivation, and results.
- #7: Story of my first pull request. The situation, motivation, and results.
- #8: Story of my first pull request. The situation, motivation, and results.
- #9: Story of my first pull request. The situation, motivation, and results.
- #10: Story of my first pull request. The situation, motivation, and results.
- #11: Story of my first pull request. The situation, motivation, and results.
- #12: Story of my first pull request. The situation, motivation, and results.
- #13: Story of my first pull request. The situation, motivation, and results.
- #14: Story of my first pull request. The situation, motivation, and results.
- #15: Story of my first pull request. The situation, motivation, and results.
- #16: Story of my first pull request. The situation, motivation, and results.
- #17: Story of my first pull request. The situation, motivation, and results.
- #18: Story of my first pull request. The situation, motivation, and results.
- #19: Story of my first pull request. The situation, motivation, and results.
- #20: Story of my first pull request. The situation, motivation, and results.
- #21: Story of my first pull request. The situation, motivation, and results.
- #22: Story of my first pull request. The situation, motivation, and results.
- #23: Story of my first pull request. The situation, motivation, and results.
- #24: Story of my first pull request. The situation, motivation, and results.
- #25: Story of my first pull request. The situation, motivation, and results.
- #26: Story of my first pull request. The situation, motivation, and results.
- #27: Story of my first pull request. The situation, motivation, and results.
- #28: Story of my first pull request. The situation, motivation, and results.
- #29: Story of my first pull request. The situation, motivation, and results.
- #30: Story of my first pull request. The situation, motivation, and results.
- #31: Story of my first pull request. The situation, motivation, and results.
- #32: Story of my first pull request. The situation, motivation, and results.
- #33: Story of my first pull request. The situation, motivation, and results.