That got me thinking about some recent discussions, arguments and even fights in the KDE community in the past few months. Some arguments are exciting. You hear the deep thinking, the examination and presentation of fresh points of view, and hear people thinking together. This is what we want for every conversation! But sometimes instead, you hear criticism, to which the reaction is defensiveness. This is painful to watch, as both (or all) sides are injured, and their hurt is being ignored.
What makes the difference? It seems to me what is lacking in the second scenario is trust. Haidt advises asking people for their advice and judgement about you, and listening with an open mind and heart. That is rather hard to do when it is your project that is being measured and criticized. Yet it is critical to success, because we often literally cannot see flaws in our processes and products that others can see quite clearly.
One thing that has bothered me for years in the whole FLOSS movement is the attitude towards users, as "lusers." I know that started out as a pun, but it seems to me that it correctly labels the orientation that developers often have. Good projects have people who use bug reports, critical blog posts and complaints on the lists, forums and IRC as feedback, in order to not just fix crashes, but to make their product better. Projects in trouble make it difficult to file bugs, or simply ignore them, and rather than viewing criticism as feedback, interpret it as a personal attack.
Unfortunately, I am seeing this defensive attitude far too often lately in KDE. This can happen within teams, when someone proposes a new idea, and then others shoot it down. I don't mean they dispute the idea, or propose a different alternative, but rather state the criticism in a take-no-prisoners way. I've also seen this after a release, when an aspect of the new application or feature is criticized by users. Rather than collaborating with the reporters, to make the application or feature better, the discussion is framed as a war by both sides. In other words, "KDE developers are dictators" vs. "KDE users/distributions/packagers hate progress".
Guess what? Wars aren't productive of good software, and are destructive to every combatant and even those within earshot. Fortunately, later I heard Ed Catmull, the co-founder of Pixar Animation Studios and president of Pixar and Disney animation, about managing creative people and his new book Creativity Inc: Overcoming The Unseen Forces That Stand In The Way Of True Inspiration. Catmull gives the credit for the success of Pixar to an open, nurturing work environment. I think we need to focus on this more in our community. It should be safe for anyone to talk to anybody. According to Catmull, at Pixar they assume that any movie is crap when they start out. But somewhere in the idea is some spark that can become great. He says,
I've spent nearly forty years thinking about how to help smart, ambitious people work effectively with one another. The way I see it, my job as a manager is to create a fertile environment, keep it healthy, and watch for the things that undermine it....The thesis of this book is that there are many blocks to creativity, but there are active steps we can take to protect the creative process....identifying these destructive forces isn't merely a philosophical exercise. It is a crucial, central mission.He used a term I love, candor. He says that creating a safe space where people can fully express their thoughts and feelings is key to keeping creativity flowing. Of course I'm going to read this book! Here is the interview (11 minutes): kuow.org/post/president-pixar-and-disney-animation-fostering-creativity.
We already have the Team Health Check which can be found here: permalink.gmane.org/gmane.comp.kde.devel.plasma/19755. I'll use Catmull's book to look again at that team tool, and see if it can be improved.
For now, I hope that before any of us speaks or writes, we'll think about our choice of words. Candor is crucial. Remember though, that feedback can be framed as helpful information, or as an attack. You might mean your feedback as helpful, but can it be read as harsh criticism? If so, please edit before publishing. Developers, think about how to invite candor, by asking others for their honest feedback. Welcome reports of problems, bug reports, and respond in a collaborative way. If you need someone to triage bugs to keep sane, ask for that help! Everything you can do to lower the barriers to honest criticism, the better your work products will be.