At a party, if you notice someone has food stuck in their teeth, you probably wouldn’t go “HEY! You have food stuck in your teeth and it looks GROSS! I hate it. I think you should go brush your teeth right now!”
But we do that all the time in open source.
Someone writes a new blog post or a new piece of code or forgets to post something … and we criticize them in public. Because it’s open source, right? Instead of emailing them we think their blog post is wrong, we leave a blunt, often rude comment. Instead of IMing them and asking if they’ve considered the privacy implications of their change, we write a public blog post that details how wrong their strategy is. Instead of congratulating them on their new product website and emailing them a few suggestions that would make usability better, we write a long critique in a blog post of our own.
When we do this, this public criticism, we change their ability to respond to it. Now they must respond in public, often defensively. If the feedback was private first, it would be easier for them to change quickly and nimbly. (Or maybe they don’t need to change at all. Maybe we missed something.)
There is a time and a place for public critique. But it’s often not the first place the critique should happen if we want to effectively influence projects.
Most effective people on open source projects communicate privately first.
They communicate via private emails, IMs and even public IRC channels, which are less public than web pages and public mailing lists because they aren’t archived.
So the next time you read something and have burning feedback, consider your audience and how you might most effectively drive the change you are looking for.
Another way to look at it: “Does this criticism have value for someone other than the person who wrote the thing?”
For instance, providing feedback on a patch generally needs to occur publically, both because others on the same mailing list may need to further comment on the feedback, and because people trying to learn about a project will learn quite a bit about project conventions by lurking on the list and reading patches and feedback.
On the other hand, if someone writes a blog post, and you find some typos in it, reporting them by private email seems preferable to leaving a comment, because nobody other than the author will get any value out of that comment. (A good reason to have your email readily findable from your blog: if I can’t find it quickly, I’ll leave a comment, because I’d rather leave a comment than not report something at all. If you potentially want private feedback, make private feedback channels available.)
If you’re going to flame, then doing it in private is better than doing it in public, yes. But wouldn’t it be even better than that, where possible, to provide constructive, collaborative feedback?
The blog post neglects exceptions? Provide a public comment like “how would you deal with it if the files aren’t writable?”
That achieves the correction, protects the originator’s feelings, and models effective interaction for all the readers.
Agreed – better to keep it public, *and* keep it clean.
The comparison with food in the teeth misses the point, because such a thing really is embarrassing and of no relevance to anyone else. But technical feedback is everyone’s business – it serves to remind/inform others of the right way of doing things, and provides others with the ability to offer further advice, or to disagree with the criticism.
Much like this blog post, really.
Technical feedback can be just as personal as spinach in your teeth. It reflects on you. While we often try to keep it objective, most of us feel pretty personally about the code and words we write.
I agree, but being able to accept criticism without offense is a vital skill for anyone. When you have paying customers, they certainly don’t hold back when you’ve messed up, and aren’t in the slightest bit interested in your hurt feelings.
Now, I don’t mean that everyone should feel free to be as rude and offensive as they like – some people do scare off newcomers by being unnecessarily harsh. But they *should* be free to offer fair and honest advice, in the expectation that the recipient won’t be unduly offended by it.
I think there are two aspects to this.
1. All feedback should be constructive.
2. People shouldn’t take technical feedback personally.
If both those are followed, then feedback can and should be public, so that the process is visible. The process is more important in open source than the end product, because there is no end product, it’s always changing.
If you can’t take technical feedback non-personally, you are not going to go very far.
That’s one of the many reasons the Linux kernel is so successful. People call crap crap, and if someone can’t handle that fact, they should be working on less important things.
All too often, people call dumping over someone else’s work “technical feedback”. It’s a get out of jail free card.
By all means, ask questions, suggest improvements, but you mention the kernel as a best practice – I’m of the opinion that the kernel gets people who are happy in that environment, and doesn’t get anyone who isn’t.
Personally, I wouldn’t be happy spending a lot of time involved in a project that had a kernel-level of discourse.
Dave.
One thing I have run into is that the people who are most likely to openly flame.. are most likely to yell out at the party that there is spinach in your teeth.
This seems to have a strong triggering mechanism as then everyone starts talking about it or commenting to others about their spinach. My guess is that it clears some sort of social taboo switch in people’s brains and everyone follows example.
The problem is that the reciprocal doesn’t happen. You can start acting like a jerk (or “frank”) but it doesn’t mean you automatically become able to handle such “frank” discussion. Instead the brain will still act attacked, socially castigated, etc and the party becomes a sullen mess.
A couple of points.
First,
Blog authors have the ability to moderate the comments on their blog. They have full control over which comments are made public and which comments remain private. If they choose not to pre-screen comments, they’ve made a choice to encourage open discussion by default regardless of the topical nature and emotional content of the comments. If “you are doing it wrong” comments are unwelcome and are embarrassing to the author, they author should have the ability to pre-screen and cull and can use that to reinforce social patterns of personal interaction and to take a conversation private pre-emptively if needed.
Secondly,
Not all blog authors provide additional contact information in the context of their blog. You provide contact information hidden in the About page of this site, but there’s no suggestion on article pages in the context of the comment form concerning your preference with regard to which feedback mechanism you would prefer. When in doubt the easiest mechanism available is the one you have to expect people to use. The comment box is absolutely the easiest to reach for. If more authors had a small snippet that said “please email me at blahblah if you have concerns or criticisms about what I have said here” ahead of the comment block if pre-screening of all comments is undesirable from the author.
-jef
And blog posts are often meant to start conversations. But I think this most often happens on mailing lists. Or within projects where people know each other.
Oh trust me on this…. private email is not a solution to bad bahavior. Either the person in question just needs to have social norms reinforced or they are just delibrately acting badly and they will use that private conversation to best benefit later on.
My day job sees a lot of private email between distributed “collaborators” as we do not have a central mailinglist..not even a private one…..and this work is not yet “open source”. Don’t even get me started. A little sunlight and some public accountability would work miracles.
So what happens repeatedly in my situation is private email conversations reach a point where there is a significant disagreement and then others get added at the current tip of the conversation without full context of everything that has already been argued and discarded. They are added to the conversation specifically to put political/social pressure on the the other person to gain perceived advantage leading up to cencensus decision making. Horrible.
Trust me on this, transparent conversation in a mailinglist is much better than private disgreements where there is more than 2 stakeholders. Either you work with people who know how to be civil and who know how to interact via text based mediums (both reading and writing to reduce emotional leakage) or you don’t. Private email conversations are a timebomb waiting to go off because once you take it private the bad actors in the conversation have a lot more control on how that private conversation is rebroadcasted again out of context.
-jef
I very much disagree. Feedback *about the work* , both negative and positive, should be in the open, because it gives volunteers a chance to help solve the issue. That doesn’t mean rudeness should be accepted. It just means feedback shouldn’t be rude. Besides, if someone has food stuck their teeth, the general assumption is that it is unintentional. I’m having trouble figuring about what the code review equivalent of seeing food stuck between someone’s teeth is. Were there a couple of incidents that sparked this blog post?
There were a *lot* of incidents that sparked this post … and in all of them I think the thing that was commented on was unintentional. The usability of the site wasn’t great unintentionally. A group wasn’t notified of a design change unintentionally. etc.
I see this all the time, and I’ve probably done it myself on a few occasions. That’s a great analogy that really gets to the social impact we have when we aren’t polite online. Alienation isn’t a great motivator if you actually care about having a discussion.
Often it is just easier to just write a comment or your own blog post than to try and communicate in private from outside the community:
* What is the author’s email address?
* What IRC channels do they reside in? What is their nickname? What times are they available?
* What mailing list can they be reached on? Do I have to subscribe first?
* What IM services do they use? What are their identities? Do they have to accept my invitation to communicate first?
For example, on this blog the only contact details are your name, Twitter ID and LinkedIn profile. Twitter is not a place for conversations of this nature and LinkedIn requires a considerable amount of effort to contact you (assuming one even has a LinkedIn account.)
I agree that the right kind of communication is an important aspect of positive influence on a fledgling project and that role falls on the community, but the role of providing a means to communicate in a constructive way falls on the author or project.
If a comment box on a blog post is the first form of communication people see, people are going to use that.