On Fri, Jun 11, 2010 at 4:49 PM, Michael Snow wikipedia@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.
Ugh.
You are implicitly expecting that the patch submitter and the code reviewer are staff members, and that the patch submitted is not very good! ;-)
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.
-- John Vandenberg