Thanks to Brian for the thoughtful response, even though it's discouraging!
Maybe this is the video referred to:
https://www.youtube.com/watch?v=RfJDDn--8lY
It's linked to these notes:
https://phabricator.wikimedia.org/T114419
There are suggestions that each part of the code should be "owned" by a
particular individual or group, who would have an obligation to accept or
reject patches in a timely fashion.
Maybe a group of "evaluators" should each be called on to evaluate each patch
on multiple dimensions (security, correctness, style, efficiency, ...), and
then there should be an algorithm for converting those evaluations into a
decision to accept or reject the patch within some time limit. That way nobody
has to take all the blame. There could be a veto power. The algorithm could
evolve over time. Evaluators could get credit for making evaluations. Each
evaluator could skip some evaluations, or answer "didn't have time to study" on
some dimensions. A consistent lack of time might render someone unsuitable for
the role of evaluator. A rejected patch would at least get a list of reasons,
such as "too few evaluators had time to study it" or "too many evaluators
labeled it as an unacceptable security risk".
Tom
> On Sep 21, 2017, at 7:21 PM, Brian Wolff <bawo...@gmail.com> wrote:
>
> 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 <
> tan...@wenlin.com> wrote:
>> 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: wen...@wenlin.com Web: http://www.wenlin.com
>> Telephone: 1-877-4-WENLIN (1-877-493-6546)
>> ☯
>>
>>
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
