One of the great joys of the internet is that no matter how obscure of an interest you have, there is normally a simple way to find people who likely share it. What was once relegated to obscure books can now have a bbs and irc channel dedicated to them. People from all over the world can learn from the collective experience of their peers, and share their own experiences with subjects that most people you may contact on a regular basis will not have even heard of. It’s wonderful!
….except, when it isn’t.
With every group, regardless of how small or obscure, there is now an almost learned behavior to lean into elitism and polarized discussion. I’ve read commentary on how this has developed over the last few years, but rather than quoting papers about the emergence of trolls (internet, not mythological), allow me to simply make a few short suggestions on how to keep criticism as productive as possible when it comes to the FOSS world.
1). All criticism should be centered around a need for improvement. There is absolutely no benefit to having a huge discussion that revolves around an issue that doesn’t stand to improve on a project. I would compare this to the overweight boxing fan who insults a fighter’s style, without the least bit of experience in the ring themselves. If it’s a discussion for the sake of discussion, it will probably be avoided by the people who are actually working on making the project better.
2). If possible, provide both reasons and a working example to a potential change. Let’s say that you’re looking over someone else’s script. Saying “You use too many pipes” is not nearly as beneficial as “Here is how I would do the same thing <insert example>. Doing this cuts the pipelines in half, which reduces resource usage significantly.” If you can’t improve on the original, then most of the time your input would be better placed in bug tracking.
3). Context is important. Some things that are shared are simply “Jumping off points” for ideas. Not everything is a polished or finished product, and this is especially true for many bbs or irc examples. Criticizing the formatting of something that starts with “Well, this is a pretty cool way to solve ____ issue,” is most certainly a waste of your time and the author’s, and everyone who will subsequently read it. While you may get the satisfaction of patting yourself on the back for having such amazing syntax skills, it’s very possible that you’re just being a nuisance. When it comes to a finished product, then you can and should make pull requests to the source tree over these subjects. At this point, it isn’t criticism at all, but simply sharing the workload of the project for a better outcome. The context in which the subject is brought up is the difference, and make sure that any criticism is in line with the subject’s goals.
4). Action is always more important than criticism. This ties in with the example above, but it’s important to keep perspective on who it is that is doing the work. Many authors and testers are doing whatever they can using their own time to provide free solutions to the public, and are not personally benefiting from their efforts at all. While constructive criticism can be a good thing if directed correctly, it is hugely beneficial to take some of the load for implementing changes onto yourself.
5). Debate is a last result, and probably signals the end of any kind of possible benefit. In all of the actionable cases, there is always the possibility that the author’s goals won’t align with yours. This happens. If you’ve provided reasons for change and workable changes, and the other side of the discussion is still adamantly opposed to them, then you can always fork the project to implement changes on your own branch. The natural selection of code then becomes the defining factor on who was right. Keep in mind that this may also mean that you will be providing support on the branch, implementing bugfixes, and generally maintaining a project. If this is out of the question, then perhaps it’s best to make your point and move on. Extended arguments very rarely change anyone’s mind, and simply serve as background noise to an otherwise productive project.
While I’m sure this doesn’t cover all aspects of criticism, I think that simply being really mindful of who is working on what project will generally be helpful to everyone who is out to provide genuine help. To those who are out to criticize others just for the sake of being a critic, find a new hobby. 🙂