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 :-)

Thanks,
Sue





-----Original Message-----
From: Chad <[email protected]>
Date: Fri, 11 Jun 2010 07:13:37 
To: Wikimedia Foundation Mailing List<[email protected]>
Subject: Re: [Foundation-l] Community, collaboration, and cognitive biases

On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <[email protected]> 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.

-Chad

_______________________________________________
foundation-l mailing list
[email protected]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________
foundation-l mailing list
[email protected]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Reply via email to