The document outlines 5 unspoken rules for contributing to open source software: 1) Justify your proposed changes, 2) Be willing to discuss and revise your contributions, 3) Be positive and grateful, 4) Make small, focused changes that are easier to review and accept, and 5) It's often easier to create companion software rather than modify existing code. The document provides examples and explanations for each rule to help new contributors successfully participate in open source projects.

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

32. Thanks!
Questions and Suggestions?