Wikipedia is the greatest encyclopedia in the world, due in large part to its openness,
including its "be bold" policy:
https://en.wikipedia.org/wiki/Wikipedia:Be_bold
The MediaWiki code is also great, and has a lot of room for improvement, which will happen
faster if code changes are treated more like wiki content changes. While anyone can edit
Wikipedia content, only a relatively small group has authorization to approve MediaWiki
code changes. This difference may be partly justified, supposing that code changes can do
more harm than content changes. Still, there appears to be a problematic bottleneck.
Efforts to improve the code are wasted when users submit patches that just sit and rot
without being approved or rejected. I've seen this: a bug is found and reported; a
patch is submitted; nothing happens for a year and a half; the patch gets out of date,
then gets updated and submitted by another programmer; several months later nothing has
happened. Unless this is a rare exception, problems like it seem bound to result in a lot
of wasted effort, and in programmers deciding not to risk wasting further effort.
Maybe the authorized group is too small and can't keep up with the patches. Maybe the
group is too cautious, either to authorize or reject patches, or to invite more people to
join it.
How about a policy to be bolder with code changes? Possible ways: (1) enlarge the
authorized group; (2) encourage the group to approve more changes; (3) enable more kinds
of approval, such as "I haven't had time to test this patch or study it very
carefully, but at least I've read it and I'm fairly sure it's not malicious or
a security risk"; (4) be especially quick to approve patches that only change
comments or variable names, without affecting code execution, since their potential harm
is minimal, analogous to editing wiki content.
Understandably, nobody wants to be blamed for letting someone into the authorized group
who turns out to have bad judgment. If the group nevertheless really needs to be enlarged,
how can it become bolder about letting people in? Similarly, nobody wants to be blamed for
approving a patch that turns out to cause a new bug, especially if the penalty for one
such mistake might outweigh the rewards for approving many beneficial patches. How about
increasing the rewards and decreasing the penalties? What signs of appreciation do the
gatekeepers receive for the number of patches, or new members, they approve? Approving a
bad patch, or an inappropriate group member, once in a while but not too often, could be
viewed positively as an indication of boldness rather than recklessness.
I hope these suggestions are helpful. They're offered in the spirit of "being
bold", even though my understanding of the organizational problem, and my experience
with submitting patches, are very limited.
Best wishes,
Tom
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wenlin(a)wenlin.com Web:
http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯