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

[phoebe ayers]

On Fri, Jun 11, 2010 at 8:22 AM, Michael Snow <wikipedia at verizon.net> wrote:
> Chad wrote:
>> 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.
>>
> The replies to my comment are missing the point. Sure, the developers
> themselves need to be able to handle public criticism of their work,
> just like wiki editors. But I was responding to Austin's comment in
> particular about board members being cautious with their opinions. In
> cases like that, there are additional concerns, like the propriety in
> publicly critiquing someone's work when you also can presumably
> influence their continued employment. That requires that certain
> feedback go through other channels, even when the same feedback could be
> given openly if it were coming from the general public.
>
> --Michael Snow

If I understand Michael's point it doesn't have anything to do with
code. Insert "criticizing how the Foundation is managed" here instead,
and I think it makes more sense. Nobody wants their boss to publicly
provide an evaluation of them to the world (even if it's not all
negative, and even if it's only about one part of a greater whole.)

The Board is in a particularly touchy position here, because they are
providing guidance and oversight for the whole Foundation, including
the performance of the E.D., who in turn can hire and fire people. But
it was recently pointed out to me that they are not the only ones;
given how our community *does* work with bottom-up leadership, if a
respected community member speaks out criticizing something they are
likely to be listened to, and the sting of criticism felt, regardless
of the outcome. It is easy to give such criticism -- just about as
easy as typing a Foundation-l message -- but not many of us subject
our own personal work to ongoing potential for public criticism like
this (not even on-wiki, except for administrators and those routinely
doing controversial things).

This is where Sue's note on having mutual respect is applicable, I
think. And yes, I imagine how criticism affects you depends on your
personality, and what the job at hand is. I don't mind criticism at
all... unless you criticize my writing, and then I get instantly more
touchy. Am I a perfect writer? Obviously not, and I have no
expectation of being so, but my reaction is instinctual because it's
something I care about. We all have our issues like this, I think;
often you don't know what they are for someone else. Keeping a tone of
respect helps.

I believe there is a particular additional issue with the
staff/community divide in that there are differing expectations when
you are assigned a job and when you take that job on yourself with no
managerial control. I have done both as a Wikimedia volunteer -- I
have been assigned jobs in the context of Wikimania, and it feels
quite different from being bold and choosing to do something yourself,
regardless of whether you're getting paid or not. This is not a
good/bad difference, simply a difference -- and one that I think we
need to collectively consider in the context of how community
governance and the process of "bold, revert, discuss" should work for
a staff-community project like usability.

-- phoebe