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

[Michael Snow]

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