00:00:15.759
As open source developers, we spend a lot of time pushing code up to GitHub. We merge pull requests, also on GitHub, and we spend time trying to figure out why our builds have failed, yet again. At times, we're looking for places to fix our bad code, and we use some incredible tools to do this.
00:00:26.320
When things are going well, we are wonderful to each other. However, when things go wrong—and they go wrong much more than we think—we can be quite terrible to one another. This experience isn't unique to the Ruby community; it happens in various places within our community and elsewhere.
00:00:37.120
There's a flow of vitriol that can resemble a fire hose, but ultimately, open source isn't just about code; it's about people and how we treat them on a daily basis. We're more than just the usernames we see on platforms like Reddit or Hacker News. As Ash Dryden said at Ruby Midwest, "It's people all the way down."
00:00:51.840
As a community, we generally do a good job of treating people well, guided by the principle of "Minnesota Nice." However, we all stand to gain by consistently being awesome to one another. This way, we can create more positive experiences and fewer negative ones. After all, we don't want people to feel trapped in a minefield with no way out.
00:01:06.720
For the next little while, I want to share some things I’ve discovered that can help us improve as a community and continue our tradition of community awesomeness without inadvertently creating drama.
00:01:20.000
I have a specific example that I want to discuss from ten years ago involving an open source project called KDE. If you're not familiar, KDE is an open-source desktop environment for Linux. It was 2003, and just ten days prior to making a particular commit, I had just received access to KDE's CVS repositories.
00:01:27.520
At that time, there was no Subversion, no Git; it was CVS! On a boring day, I decided to find something different to work on outside my usual focus, which was messaging protocols and instant messaging clients. So, I hopped onto IRC and began to poke around for tasks. I was informed that I could help on some code by adding null checks to ensure the code wouldn't crash. This task took about an hour, consisting of ten minutes of actual coding and forty minutes of compilation.
00:01:47.680
After completing the task, I received a rather curt reply. I remember thinking, 'Whoa, wait, what just happened?' I was caught off guard and perceived it as a lack of support; the response felt harsh and dismissive.
00:02:00.480
That experience profoundly impacted me and my contributions to that section of code. After my first commit in 2003, I contributed roughly ten more times over the next eight to nine years. My next contribution occurred nearly two years later, which was simply to fix a build issue. Then another fix enabled my email to work properly. Ultimately, that initial harsh reply led me to think that new contributors were generally unwelcome in that part of the community.
00:02:21.360
Sadly, this type of exclusion happens frequently, either in the Ruby community or in others. So my first tip for you is to avoid responding in anger. There are many things you can do to make those situations better. If you're feeling angry, remove yourself from the situation, do something else, and come back later to reconsider your response.
00:02:42.400
If you revisit the situation and you're still angry, walk away again. Engage in some exercise or take a break—anything to help you clear your mind. When you eventually respond, I guarantee it will be a hundred percent better than the hasty response I initially received.
00:03:05.760
Now that we've addressed anger management, let's talk about the pitfalls of jumping to conclusions. I frequently fall into this trap and often regret it. For instance, in a recent project where I worked on upgrading to Rails 4, a developer kindly informed our community via email that he had merged his changes. In my haste, I reacted too quickly without checking the announcement.
00:03:17.760
My response ended up being ill-received because I hadn’t done my diligence and had forgotten to see the prior communication. This mistake made me look foolish and, frankly, a bit of a jerk. Therefore, the next tip is to put yourself in someone else's shoes before you share your perspective; this strategy can prevent misunderstandings and unnecessary conflict.
00:03:34.560
I want to pose a question: What do you think is one of the main issues facing contributions in open source projects today? Many reasons stem from this challenge; notably, a vast number of people choose to start their own projects rather than contributing to existing ones. This reality can make establishing a vibrant contributor base challenging.
00:03:52.480
Another contributing factor is that many individuals pursue open-source projects as a learning opportunity, while some simply lack the motivation to contribute. Consequently, we often find that 80% of the work is completed by only 20% of the people involved in these projects.
00:04:16.760
This brings us to the issue of how we can encourage greater participation. Simply telling someone to "patch accepted" isn't effective, nor is it the best way to welcome input or contributions. Having experienced this personally, I can attest that an indifferent response discourages potential contributors.
00:04:30.320
A more constructive approach is simply to convey that you're willing to accept contributions. Invite contributors to help and reassure them that their efforts are welcome. Just recently, I merged a pull request from someone who contributed for the first time, and all I did was prompt her with a question and point her toward where she could make changes.
00:04:52.720
This approach illustrates tip number three: always ask questions rather than give orders. Even if you hold a leadership role, avoid acting like a dictator. We're more likely to attract contributors when we promote collaboration and support each other.
00:05:05.520
Pair programming can be a fantastic way to encourage involvement and help keep contributors engaged. As Mark illustrated in his lightning talk, offering help demonstrates to potential contributors that you, as a project leader, value their contributions and wish to foster a collaborative environment.
00:05:17.760
This leads us to tip number four: if you're providing assistance to someone, you are being absolutely awesome. By being supportive, you're creating positive experiences for others in your community.
00:05:37.680
I love to see contributions merged, and I particularly enjoy offering responses that encourage others to keep creating and contributing. A positive response can motivate a contributor to submit more pull requests, leading to ongoing engagement in a project.
00:06:04.640
Another aspect that brings excitement to projects is the use of emojis and fun comments, helping to create a friendly atmosphere. Using enthusiastic messages can fill a project with a sense of whimsy and recognition for contributors.
00:06:20.240
Ultimately, I want to emphasize the importance of offering praise and encouragement frequently. Recognizing others, even for small contributions, helps newcomers feel valued and nurtured.
00:06:31.040
To wrap things up, we excel in fostering kindness within our communities, but we can always improve. Just as businesses aim for happiness—whether it's customer or employee satisfaction—we should focus on optimizing for kindness. If you're interested in improving further, I highly recommend reading the book that has informed much of this talk.
00:06:48.880
It’s an older book—the version from 1981 is highly recommended—having been in print since 1936, and its earlier insights are incredibly relevant.
00:07:05.600
Thank you for your time. My name is Matt Rogers; I go by Matar with an underscore on Twitter. This has been "Open Source Pro Tips from the Trenches," and I'm happy to take any questions or engage in discussion before I conclude.
