[Foundation-l] Community, collaboration, and cognitive biases

susanpgardner at gmail.com susanpgardner at gmail.com
Fri Jun 11 18:25:28 UTC 2010

Chad, I'm hesitant to reply to your note, because I feel like "defending the staff against the community" is a bad role for me: it tends to polarize and divide, rather than helping us all work together well.  And I think I do, for the most part, agree with you.

(As someone pointed out here the other day, Wikimedia recruits with that in mind: all our job postings specifically call out that people need to be comfortable in an open, collaborative environment, and we aim to only recruit people who can thrive in that context. We've learned the hard way to really probe on that in hiring interviews -- to pose open-ended scenario questions, and to use real-world examples. Practically everyone believes they are inclined to be collaborative, but that doesn't mean their definition is the same as ours.  And we've found, unsurprisingly, that people who are already members of the Wikimedia community are pretty much the only people guaranteed to be risk-free in that regard: to a certain extent, hiring outside the community always carries a certain amount of risk.  Which is fine and unavoidable: we do what we can to pick people we believe can succeed.)

But I do want to make one small point that I think is sometimes missed. And that is, the staff can't take wikibreaks.  Volunteers are always free to take a break if they get irritated or discouraged or stressed: their contribution is voluntary, and they can walk away any time.  The staff can't. They need to come in every day and work hard, even on those (fortunately fairly rare) days when they are getting yelled at on mailing lists, when it might be harder than usual to feel motivated.

We try really hard to hire people who are personally resilient, and I think we've succeeded at that reasonably well. Personally though, I think harshness and offence are mostly avoidable, and I think we should avoid them whenever we reasonably can.  (Of course, I am female, and women are socialized to value harmony more than men.  It doesn't stick for us all, but it did stick a fair bit, for me.)  Personally, I think it's mostly possible to be frank without being rude, and I think it's worth trying to do that.  I'm not arguing that people should handle the staff with kid gloves: I would actually argue, and have argued, that an uptick in kindness would be good for everyone.  I realize that not everyone needs that, and it's obvious that not everyone will get it, whether they need it or not.  But I think it's a worthy goal :-)


-----Original Message-----
From: Chad <innocentkiller at gmail.com>
Date: Fri, 11 Jun 2010 07:13:37 
To: Wikimedia Foundation Mailing List<foundation-l at lists.wikimedia.org>
Subject: Re: [Foundation-l] Community, collaboration, and cognitive biases

On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <wikipedia at verizon.net> wrote:
> ...if for example I was qualified to review a
> staff member's patch (which I'm not), I might want to think twice about
> what audience gets that feedback.
> --Michael Snow

Why? If they're contributing a patch to MediaWiki, they should go
through the same public patch/feedback -> commit/feedback cycle
as everyone else. The only acceptable time to develop in private is
when we're looking at active security vulnerabilities, and even then
once a patch has been written the code is committed and the issue
becomes public knowledge.

Can we be a bit harsh sometimes? Sure. But we're equal
opportunity offenders here. Anyone who submits code--staff or
volunteer--is subject to the same treatment on Bugzilla and Code
Review. If your patch sucks, we're going to tell you about it, and
there's absolutely no reason to sugarcoat it.

If someone can't take public criticism, then quite frankly they
probably shouldn't be working on open source software.


foundation-l mailing list
foundation-l at lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

More information about the wikimedia-l mailing list