On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow
<wikipedia(a)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