Re: [Wikitech-l] Be bold with code changes

Code review latency is a complicated issue which a lot has been said about. It was a subject of a session at the last 2 dev summits (im not sure if the last one was recorded, but there is definitely a video of the session from the dev summit two years ago, on commons). It was an issue i used to care very much about when it highly affected me, but now that my role shifted so im less affected, i notice it much less and thus tend to forget about it (unfortunately). My personal opinion is it is a structural problem of both the wikimedia foundation and the mediawiki community, and it wont change unless deep changes are made in our processes and expectations. In any case, as far as (4) goes, id hope that is already the case. I usually just do a quick glance and rapid approve if the change does not involve code changes. If you are aware of any trivial (non code changes) that are languishing in review, please mention them on #mediawiki or #wikimedia-dev and they should be taken care of right away. -- bawolff On Thursday, September 21, 2017, Tom Bishop, Wenlin Institute < tangmu(a)wenlin.com&gt; wrote: its openness, including its "be bold" policy: 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. patches. Maybe the group is too cautious, either to authorize or reject patches, or to invite more people to join it. 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. 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. "being bold", even though my understanding of the organizational problem, and my experience with submitting patches, are very limited.