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

[Aryeh Gregor]

On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow <wikipedia at verizon.net> wrote:
> 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.

Oh, okay.  I was about to respond to you too, but I did miss the
point.  :)  What you seem to be saying is that code review should be
public, but people like board members shouldn't review code because
criticism might make people worry that they'll be fired or something.
I think you're overestimating the morale impact of negative code
review -- in serious review-then-commit systems like Mozilla uses,
virtually no code gets accepted in its original form without
modifications, even when written by experienced developers.

Someone pointing out bugs in your code shouldn't be demoralizing
unless there's some kind of insanely unrealistic social expectation
that your code isn't *supposed* to have any bugs.  That might exist in
dysfunctional corporate bureaucracies, where people are expected to
try hiding all flaws from their bosses, but in an open-source
environment where everyone finds problems in everyone else's code all
the time, it should be no special problem.

(Of course, we don't use a review-then-commit system.  Hypothetically
it's commit-then-review, but realistically more like
commit-then-hopefully-glance-over.  Personally, I'd be happy if
*anyone* seriously reviewed my code and pointed out little things I
had gotten wrong, rather than silently marking it "ok" and/or pointing
me to the bugs it caused after they've already happened.)

Needless to say, things like work evaluations can still be private!
Who Wikimedia employs isn't the development community's concern, at
least not directly.  Nor necessarily what general type of feature it
chooses to fund.  The development community *is* concerned with things
like what code gets committed and how things are implemented.  I don't
mind if the Board and CTO confer among themselves and decide "We're
going to be hiring people X, Y, and Z to work on
usability/upload/whatever", but the resulting code needs to go through
the *exact* same process that a volunteer's code goes through to get
accepted, from design to deployment.