I’ve been working with elementary and the community for quite some time now, and I’ve gotten a pretty good feel for the individuals that make up the awesome team. Not only that, but I know the direction of the project as a whole, and I help keep things on track. Heck, that’s why I’m part of the team to begin with. I’ve invested countless hours of my time into helping to craft an incredible open computing platform. So when it receives criticism, I take it personally.
Criticism is great; it helps point out flaws or differing opinions and it helps drive the project forward. By taking the criticism personally, I mean I take it in, process it, and see how I can use it to make both elementary and myself better. If the criticism is valid and helpful, I am extremely appreciative of the criticizer for pointing it out and speaking their mind. Oftentimes a bug report is filed or a meeting is held, and the criticism is addressed. The project moves ever onward.
However, there comes a point where criticism goes beyond being helpful and rapidly becomes harmful. When one storms into a room full of hard-working developers and contributors, starts bossing them around, calls them names, and says the project is doomed, it helps no one. The criticizer’s intentions may be entirely valid, but the end result is a room full of hurt and hostile people who’ve tired over something that has essentially just been called crap. The criticizer is shut out, ignored, and cut off from conversation. This is harmful all around.
We, as both contributors and criticizers, need to learn how to manage criticisms from both ends.
As contributors, our job is to take the comment, no matter how rude or hurtful it may be, and extract the legitimate criticism. Once we’ve boiled it down to that, we need to approach it just like any other bit of criticism; take it in, process it, and see if it can be addressed while making the project better. File the appropriate bug or bring it up at a meeting, and move on. If the criticism seems to be pointless or a personal opinion that is not shared by many other people, let the criticizer know you’re appreciative that they’ve shared their thoughts and that you’ll keep it in mind. Simply acknowledging the criticism can go a long way; it lets the criticizer know the thoughts were heard and that you accept they exist.
As criticizers, we must be careful to present our criticism in a helpful way. One great way of doing this is by looking at at least one positive thing for every negative thing you point out. Instead of simply shouting out everything you think is wrong (often leading to the above situation with hurt and hostile people), focus on what you like and see if you can find a way to make the negative thing better. For example, if you think the design of an app is terrible, don’t just tell the designer it’s terrible, but approach it by telling them what you like about the app, let them know you think the design needs to be rethought, and as a bonus, let them know how you think the design can be improved. This helps move things forward by getting them thinking about the issue instead of simply shutting you out.
Whenever you’re working with a large number of people, you are going to get differing opinions. To bring the common goal closer, we must all work to give and take criticism properly. If everyone simply takes the time to manage criticism the right way, we’ll all benefit, peoples’ voices will be heard, and the end result will be a better product. The next time you come across criticism, no matter which end of it you’re on, be mindful of how you manage it. Keep in mind the common goal and use the criticism to bring the project closer to that goal.
Thanks to all of our supporters, backers, and customers! Your contributions make elementary possible. If you’d like to help build and improve elementary OS, don’t hesitate to Get Involved.