On Fri, Jun 11, 2010 at 4:49 PM, 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.
You are implicitly expecting that the patch submitter and the code
reviewer are staff members, and that the patch submitted is not very
Most open source developers have been lambasted in a public code
review; they either pick up their game and look back at their previous
code and cringe, or they go work for a company that has ten layers of
bureaucracy to protect their feelings and prevent their crappy code
from making it into the wild.
The content community is constantly putting up their work for public
review, and working collaboratively with the reviewers.
The simple solution is: Don't employ bad coders! ;-)
Or said another way, require that applicants have existing open
source/content contributions under their belt (preferably on
mediawiki/wikimedia), so that you can inspect the caliber of their
work before employing them.
With Mozilla, patches are uploaded onto bugzilla for review by *the
community*. Code review comments go on the *public* bug page. etc.
Staff members talk privately among themselves, but then so do
community members. No special process for staff vs community; the
only difference should be that the priorities of the staff are
strategically set by the organisation.