On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow
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.
Well, board members shouldn't review code because they're mostly not
qualified to do so. The comment as it relates to morale is a more
general point, it's not limited to the specific context of MediaWiki
development. So it's less about how the process side of code review
should work, and more about the organizational challenges for the
foundation in interacting with community or public process. I think
that's also related to what Rob was trying to say in different terms.