Not for the first time, and certainly not for the last time, technical progress was stymied by collective thoughtlessness today. This thoughtlessness, this inability to see the humans at the other side of the internet, makes the otherwise rewarding experience of releasing and maintaining open source projects immensely stressful. What's worse that, oftentimes, we're essentially on the same side, except for a few trivial differences that our egos won't let us put aside. This thoughtlessness is insidious – you can easily slip into it in the heat of the moment.
Usually I'm pretty inured to seeing this behavior, but today I watched what could have been a productive, insightful conversation on an issue thread spiral into pointless, combative thoughtlessness. There was a lot of promise there, and if we could have collectively put aside our egos and aesthetics for a moment, we could have improved an already wonderful tool. One person's actions on the thread really impressed me, however. Specifically, they apologized for the tone of their comments. Their apology – and the thoughtfulness it represented – made me consider the patterns and anti-patterns of interaction I've seen and personally taken part in on Github issues.
I've listed some "do's" and "don't's" here. I've screwed up most of these things below at some point or another. I suspect most have. However, the point is not to be perfect, it's to be better than you were before. Without further ado:
¶ Don't tell maintainers what to do.
If you actually care about effecting change, don't tell maintainers that they "have to", or even "should" change their project. They do not owe you anything. It is counterproductive to start a conversation this way: you're likely to put them on the defensive. It takes active work on their behalf to come back to a neutral position from that point. In other words, you're setting yourself up for failure.
Instead, try to put maintainers in your shoes. Show them your perspective, and try to get them on your side. They've probably got a different view of their project and its relation to the outside world. By giving them useful feedback, you're not only improving the chance of your desired outcome, you're helping the maintainer clarify their understanding of how their project is being used in the wild.
¶ Don't question the maintainer's decisions.
Yes, that webpack user has heard of browserify. That lodash user is aware of the builtin Array functions, and that person using underscore is probably aware of both. An issue that asks why a given project is using A instead of B, or suggests a project should use X instead of Y, is almost always self-serving. Don't let personal preferences masquerade as technical differences.
Open source projects are not a zero-sum game. The use of projects you don't agree with does not affect you in any material way. I know it seems like they do, but they don't. Many roads lead to Rome, there are lots of ways to skin a cat, etc. Resist the urge to comment about methodology – it doesn't matter to the maintainer, whose project already works. Such transparent attempts to spend the maintainers time and attention to bolster your world-view doesn't engender trust that you have the best interests of the project in mind. There are ways to change a maintainers mind about technology use, but this class of issues are not amongst them.
Build trust before you suggest revisiting past decisions. Put in the time and effort to make the project better. Respond to issues. Fix bugs. Contribute code, time, or other resources. Show that you care about and use the project, and that you honestly have its best interests in mind when you suggest a different technology, or suggest a rename. If you're not willing to do this, you don't have any basis to bring a decision to question.
¶ Have empathy for the maintainers.
Before piling onto a contentious issue, picture what it's like to be proud of a project, only to receive a slew of negative, stressful emails about it in a short timespan. How do you think you'd feel? Besieged? Stressed?
Consider the other person when you're about to comment on an issue. Is this really going to convince them of anything, given the other comments in the thread? Or is it just going to put them further on the defensive?
Yes, you may be stressed out because their project broke yours, or because their project threatens your existing time investments in other approaches, or a myriad of other ways. However, the maintainer is at the focal point of a lot of people stressed out at them. Venting your stress at them – as temporarily relieving as that may feel – does not fix anything, and can even poison the conversation such that no one can make a good argument.
¶ Apologize when you mess up.
It takes conscious effort to avoid falling into the trap of thoughtlessness. We all lapse from time to time, especially when we're passionate about the topic. What's important is to recognize those lapses, and make sure that the person on the receiving end knows that you are aware that it was a mistake, and are sorry for forcing them to deal with it. Acknowledging this does not weaken your position. For my part, at least, I am much more comfortable trusting those who I know recognize and rectify their mistakes than those who are supremely, quixotically confident in their position.
There's a person at the other end of that issue comment box. Being right on the internet at the expense of that person is at best thoughtless, and at worst egotistical. Consider your goals before your comment, and be unflinchingly honest with yourself. There's no need to pour more stress into the internet.