Be bold with code changes
by Tom Bishop, Wenlin Institute
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)
☯