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

[Tom Bishop, Wenlin Institute]

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  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 

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

[Brian Wolff]

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

[Wikitech-l] Be bold with code changes

[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: 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