Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Gergo Tisza]

On Fri, Jan 18, 2019 at 6:46 PM Chad  wrote:

> There _must_ be a way to disable this for certain files. Great examples:
>
> site.pp in puppet
> en.json language file in MW core
> CommonSettings or InitialiseSettings in wmf-config
>

There *is* a way to disable it. See plugins docs:
https://gerrit.wikimedia.org/r/plugins/reviewers-by-blame/Documentation/config.md

IMO the two blockers are having the plugin act under its own username and
providing some form of user optout. The other issues are annoying but can
be worked around (or opted out from in the worst case).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Chad]

On Fri, Jan 18, 2019 at 2:13 PM Pine W  wrote:

> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment.


There was no coding to start--it's an upstream plugin.

One that I considered enabling ages ago, fwiw. I didn't because of the very
issues outlined in this thread.

There _must_ be a way to disable this for certain files. Great examples:

site.pp in puppet
en.json language file in MW core
CommonSettings or InitialiseSettings in wmf-config

All examples of files that are edited by dozens of folks. Folks who could
very well be unqualified to review your change and/or completely
uninterested in it at all.

I did enable the reviewers (not by blame) plugin ages ago. This allows
people to opt in with much more granularity (and would remove the need for
the bot)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reviving 'EmbedScript' extension for sandboxed JavaScript widgets

[Brion Vibber]

Hey all!

I'm reviving an old project to embed sandboxed HTML/JavaScript "widgets"
into wiki pages as a click-to-play media type, using modern browsers'
 sandbox and Content-Security-Policy restrictions.

Intro and detail notes which I'll keep updating:
https://www.mediawiki.org/wiki/User:Brion_VIBBER/EmbedScript_2019

I hope to extend it with a headless "plugin" mode which allows less-trusted
user-written code to interact safely with fully-trusted host APIs, and a
dependency system to let common library modules, string localizations,
image files from Commons, and data from Wikidata be bundled up and used
safely, without cross-site data exposure.

I'm hoping to solicit some more feedback while I'm in the prototyping
stage, with an eye towards issues we'll need to resolve before it reaches a
productizable stage we could seriously deploy.

Open questions include:

* Can we really replace some user scripts and gadgets with a split-trust
model, and which ones are good ones to start experimenting with?
* What should a user-permissions UX look like for plugins? What threat
models are not examined yet?
* What kind of comment / code review system is needed?
* What about patches, and forks, and copies and centralization? what's the
best Commons-centric or alternate model that will prevent fragmentation of
code?
* How should libraries / dependencies work?
* How should localization work?
* How much coupling to MediaWiki is desired/required?
* How to implement mobile app and offline support?

Feel free to poke me directly or on the wiki talk page with
questions/comments/ideas. Love it? Hate it? Great! Let me know. :)

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Stas Malyshev]

Hi!

> On Fri, Jan 18, 2019 at 10:13 PM Pine W  wrote:
> 
>> I'm glad that this problematic change to communications was reverted.
>>
>> I would like to suggest that this is the type of change that, when being
>> planned, should get a design review from a third party before coding
>> starts, should go through at least one RFC before coding starts, and be

I think there's no reason to make it bigger deal than it is. There was a
feature that people thought would be good, turned out it is not as good
as expected, so it was disabled. Nothing broken, nobody hurt (well,
maybe except some inboxes...). I don't think there's a reason to
describe this situation as "inexcusable". Sometimes something that we
expect to work one way and be useful turns out different way and things
that seemed to be excellent idea turn out to be very bad one. And we
have to adjust, and this is normal. We don't like such situations, but
we know they happen, and as long as they are handled properly - and I
think in this case it was - there's no reason to make it more than it is.

>> reasonable likelihood of costing an administrator their tools, and I hope
>> that a similar degree of accountability is enforced in the engineering

I hope not. Expecting unreasonable perfection from people and processes
and overreacting when inevitable problems happen will only lead to
frustration, failure and stagnation. Every failure has some lesson to
learn, but the lesson shouldn't be "let's find somebody to punish". I am
not sure if that was the intent, but it kinda felt this way to me. And I
don't think this is warranted neither in general nor in particular case.

Thanks,
-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[bawolff]

Umm, No.

--
Bawolff

On Fri, Jan 18, 2019 at 10:13 PM Pine W  wrote:

> I'm glad that this problematic change to communications was reverted.
>
> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment. Involving TechCom might also be appropriate. It appears that
> none of those happened here. In terms of process this situation looks to me
> like it's inexcusable.
>
> In the English Wikipedia community, doing something like this would have a
> reasonable likelihood of costing an administrator their tools, and I hope
> that a similar degree of accountability is enforced in the engineering
> community. In particular, I expect engineering supervisors to follow
> established technical processes for changes that impact others' workflows,
> and if they decide to skip those processes without a compelling reason
> (such as a site stability problem) then I hope that they will be held
> accountable. Again, from my perspective, the failure to follow process here
> is inexcusable.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> 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] TechCom Radar 2019-01-16

[Kate Chapman]

Hi All,

Here are the minutes from this week's TechCom meeting:

* Looking for input on: RfC: Standards for external services that
integrate with MediaWiki 

* Accepted as a RFC: Consolidate language metadata into language-data
and use it in MediaWiki core


* Hosting IRC Discussion on Gerrit privilege policy changes on
Wednesday January 23rd 2pm PST (21:00 UTC, 22:00 CET) in
#wikimedia-office
 * Draft policy available here:


You can also find our meeting minutes at


See also the TechCom RFC board
.

If you prefer you can subscribe to our newsletter here


Thanks,
Kate

--
Kate Chapman
Senior Program Manager, Core Platform
Wikimedia Foundation
kchap...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Paladox via Wikitech-l]

 "should get a design review from a third party before coding starts" what do 
you mean by that?
Also may i remind you that gerrit is not a encyclopedia, it's a code review 
system.
So what ever process is on the encyclopedia is not the same here.
Also please can we leave the threats out. It wasn't deployed to annoy users, it 
was deployed to help. Obviously we didn't know it was going to turn out like 
this, hence why it was made opt in for all projects today.


On Friday, 18 January 2019, 22:13:38 GMT, Pine W  
wrote:  
 
 I'm glad that this problematic change to communications was reverted.

I would like to suggest that this is the type of change that, when being
planned, should get a design review from a third party before coding
starts, should go through at least one RFC before coding starts, and be
widely communicated before coding starts and again a week or two before
deployment. Involving TechCom might also be appropriate. It appears that
none of those happened here. In terms of process this situation looks to me
like it's inexcusable.

In the English Wikipedia community, doing something like this would have a
reasonable likelihood of costing an administrator their tools, and I hope
that a similar degree of accountability is enforced in the engineering
community. In particular, I expect engineering supervisors to follow
established technical processes for changes that impact others' workflows,
and if they decide to skip those processes without a compelling reason
(such as a site stability problem) then I hope that they will be held
accountable. Again, from my perspective, the failure to follow process here
is inexcusable.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Pine W]

I'm glad that this problematic change to communications was reverted.

I would like to suggest that this is the type of change that, when being
planned, should get a design review from a third party before coding
starts, should go through at least one RFC before coding starts, and be
widely communicated before coding starts and again a week or two before
deployment. Involving TechCom might also be appropriate. It appears that
none of those happened here. In terms of process this situation looks to me
like it's inexcusable.

In the English Wikipedia community, doing something like this would have a
reasonable likelihood of costing an administrator their tools, and I hope
that a similar degree of accountability is enforced in the engineering
community. In particular, I expect engineering supervisors to follow
established technical processes for changes that impact others' workflows,
and if they decide to skip those processes without a compelling reason
(such as a site stability problem) then I hope that they will be held
accountable. Again, from my perspective, the failure to follow process here
is inexcusable.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Thiemo Kreuz]

> Gerrit no longer automatically adds reviewers […]

Thank you very much for reacting so fast.

> https://gerrit.wikimedia.org/r/485184

I'm not sure if the list of issues in this commit message is meant to
be complete. But I noticed it misses the bug I found the most
annoying: The plugin doesn't get activated once per patch, but for
every patch set, and ignores every human intervention that might have
been done to this point, most notably when reviewers have manually
been removed. There are many ways to fix this, but the current
behavior is unacceptable.

It is due to this bug that I wish we would revoke this bad plugin
entirely. I don't think anybody should be able to run it as this would
open the exact same issues again, just on a smaller scale, but still
hurting the same people.

Best
Thiemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Paladox via Wikitech-l]

 I've forwarded jynus feedback upstream at 
https://bugs.chromium.org/p/gerrit/issues/detail?id=10337

On Friday, 18 January 2019, 15:01:09 GMT, Paladox via Wikitech-l 
 wrote:  
 
  The patch i linked in my other email does what you are all suggesting :) (opt 
out per project).
If done through All-Projects it will opt you out of all projects.
    On Friday, 18 January 2019, 14:44:50 GMT, Daniel Kinzler 
 wrote:  
 
 Am 18.01.19 um 15:25 schrieb Jaime Crespo:
> Let me suggest one workflow that may work with this feature- Adding a
> button, for example, with "Suggest reviewers" which you can press to get
> this effect. 

Yes.

It could also be doneautomatically when a patch did not get any attention for a
week or so.

In any case, there should be a way to opt out. Ideally, per project.


-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

___
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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Paladox via Wikitech-l]

 The patch i linked in my other email does what you are all suggesting :) (opt 
out per project).
If done through All-Projects it will opt you out of all projects.
On Friday, 18 January 2019, 14:44:50 GMT, Daniel Kinzler 
 wrote:  
 
 Am 18.01.19 um 15:25 schrieb Jaime Crespo:
> Let me suggest one workflow that may work with this feature- Adding a
> button, for example, with "Suggest reviewers" which you can press to get
> this effect. 

Yes.

It could also be doneautomatically when a patch did not get any attention for a
week or so.

In any case, there should be a way to opt out. Ideally, per project.


-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

___
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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Daniel Kinzler]

Am 18.01.19 um 15:25 schrieb Jaime Crespo:
> Let me suggest one workflow that may work with this feature- Adding a
> button, for example, with "Suggest reviewers" which you can press to get
> this effect. 

Yes.

It could also be doneautomatically when a patch did not get any attention for a
week or so.

In any case, there should be a way to opt out. Ideally, per project.


-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Ariel Glenn WMF]

In the meantime, I would encourage those who have not looked at the Git
Reviewer Bot page in a while, to do so and to add any updates.

Ariel

On Fri, Jan 18, 2019 at 4:12 PM Tyler Cipriani 
wrote:

> Hi all,
>
> Gerrit no longer automatically adds reviewers[0]. Unfortunately, this
> plugin appears (given the replies on this thread) to be missing key
> features needed to be useful for us at this time. Apologies to those
> folks whose inboxes were destroyed.
>
> I would like to re-enable this plugin at some point, provided the
> features identified in this thread are added (perhaps also an
> "X-Gerrit-reviewers-by-blame: 1" email header, or subject line to make
> filtering these messages easier).
>
> In the interim, project-owners are able to opt-in to using the
> reviewers-by-blame plugin on a per-project basis on their project admin
> page in Gerrit.
>
> Also, the Git Reviewer Bot[1] provides folks an opt-in method of
> volunteering to review a subset of files in a particular repo.
>
> Getting code review as a new contributor is hard. Thanks for bearing
> with us.
>
> -- Tyler
>
> [0]. 
> [1]. 
>
> On 19-01-17 13:51:58, Greg Grossmeier wrote:
> >Hello,
> >
> >Yesterday we (the Release Engineering team) enabled a Gerrit plugin that
> >will automatically add reviewers to your changes based on who previously
> >has committed changes to the file.
> >
> >For more, please read the blog post at:
> >
> https://phabricator.wikimedia.org/phame/post/view/139/gerrit_now_automatically_adds_reviewers/
> >
> >NOTE: There are a couple requests from us open upstream to improve the
> >plugin[0], we'll incorporate those improvements when they are released.
> >
> >On behalf of the rest of the Release Engineering Team[1],
> >
> >Greg
> >
> >[0] https://phabricator.wikimedia.org/T101131#4890023
> >[1] As well as Paladox, a Wikimedia volunteer with strong ties to
> >upstream Gerrit.
> >
> >--
> >| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> >| Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
> >
> >___
> >Engineering mailing list
> >engineer...@lists.wikimedia.org
> >https://lists.wikimedia.org/mailman/listinfo/engineering
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Jaime Crespo]

On Fri, Jan 18, 2019 at 3:12 PM Tyler Cipriani 
wrote:

> I would like to re-enable this plugin at some point, provided the
> features identified in this thread are added (perhaps also an
> "X-Gerrit-reviewers-by-blame: 1" email header, or subject line to make
> filtering these messages easier).


Let me suggest one workflow that may work with this feature- Adding a
button, for example, with "Suggest reviewers" which you can press to get
this effect. Or doing it automatically if your history only has less than X
CRs sent. What do you think?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Tyler Cipriani]

Hi all,

Gerrit no longer automatically adds reviewers[0]. Unfortunately, this 
plugin appears (given the replies on this thread) to be missing key 
features needed to be useful for us at this time. Apologies to those 
folks whose inboxes were destroyed.


I would like to re-enable this plugin at some point, provided the 
features identified in this thread are added (perhaps also an 
"X-Gerrit-reviewers-by-blame: 1" email header, or subject line to make 
filtering these messages easier).


In the interim, project-owners are able to opt-in to using the 
reviewers-by-blame plugin on a per-project basis on their project admin 
page in Gerrit.


Also, the Git Reviewer Bot[1] provides folks an opt-in method of 
volunteering to review a subset of files in a particular repo.


Getting code review as a new contributor is hard. Thanks for bearing 
with us.


-- Tyler

[0]. 
[1]. 

On 19-01-17 13:51:58, Greg Grossmeier wrote:

Hello,

Yesterday we (the Release Engineering team) enabled a Gerrit plugin that
will automatically add reviewers to your changes based on who previously
has committed changes to the file.

For more, please read the blog post at:
https://phabricator.wikimedia.org/phame/post/view/139/gerrit_now_automatically_adds_reviewers/

NOTE: There are a couple requests from us open upstream to improve the
plugin[0], we'll incorporate those improvements when they are released.

On behalf of the rest of the Release Engineering Team[1],

Greg

[0] https://phabricator.wikimedia.org/T101131#4890023
[1] As well as Paladox, a Wikimedia volunteer with strong ties to
upstream Gerrit.

--
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team ManagerA18D 1138 8E47 FAC8 1C7D |

___
Engineering mailing list
engineer...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/engineering


signature.asc
Description: PGP signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Physikerwelt]

Hi Thiemo, hi all,

given my strong support for T78768 and the connection to this change,
I would like to express my regrets to the engineers blocked by the
change in Gerrit. As typical for strike actions, it disrupts the usual
business. However, I see the positive effect that people are made
aware of the fact that the code review process needs to be improved.

While I am happy with the code review duration of the patches I submit
today, I had problems to get the (obviously bad) code I wrote in the
beginning reviewed. I guess one of the main reasons for the
improvement is that I know the reviewers in person, today.

However, visiting Hackathons and annoying WMF employees in their
offices is not something that scales. Therefore, the review process
needs to be changed. After years of discussion and only little changes
to the process, this change brings this important but not urgent topic
to the agenda, which I appreciate.

To my experience Thiemo ist one of the most predictable (=good) code
reviewers. I am more than happy that he shared his process in his
email. I think his code reviewing procedure is exemplary and should
act as a general template. Thank you Thiemo.

One last hopefully constructive point. To my experience, the most
annoying experience in waiting for CR is when multiple reviewers are
requested and no feedback is provided. My wish would be that the state
of the patch is visualized in the (Gerrit) UI. So that the submitter
of the patch knows the state of the change and can estimate how long
it might take until the patch proceeds to the next stage.

Happy coding
physikerwelt


On Fri, Jan 18, 2019 at 1:25 PM MA  wrote:
>
> Hello,
>
> I agree with what Giuseppe Lavagetto and Jaime Crespo said.
>
> In my case, I am now getting review requests from several repos I
> contributed some time in the past, but for which I'm not a qualified
> reviewer. The plugin is also adding bots to review changes such as in
> .
>
> While I think it is certainly a good idea to help people find
> reviewers for their patches, I feel this plugin as it is now is going
> to achieve the contrary (mail blindness due to too many emails).
>
> I suggest we disable the plugin until at least Paladox's blacklist
> could be implemented and so we are given the choice to opt-out from
> it.
>
> Thank you, M.
>
> ___
> 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

Re: [Wikitech-l] Gerrit now automatically adds reviewers

[Thiemo Kreuz]

So it turns out this addition is indeed the reason I get constantly
spammed with the same fake review request over and over again, no
matter how often I try to remove myself from a patch.

https://gerrit.wikimedia.org/r/484681

Not only that. The notification mails make it look like Matthias
Mullie went rogue. He is a wonderful person and definitely doesn't
deserve that such cyberbullying is misattributed to him.

With all the respect, but at this point this is just insane. Please
make this stop!

Thiemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[MA]

Hello,

I agree with what Giuseppe Lavagetto and Jaime Crespo said.

In my case, I am now getting review requests from several repos I
contributed some time in the past, but for which I'm not a qualified
reviewer. The plugin is also adding bots to review changes such as in
.

While I think it is certainly a good idea to help people find
reviewers for their patches, I feel this plugin as it is now is going
to achieve the contrary (mail blindness due to too many emails).

I suggest we disable the plugin until at least Paladox's blacklist
could be implemented and so we are given the choice to opt-out from
it.

Thank you, M.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikidata] [Wikipedia-l] Fwd: [Wikimedia-l] Wikipedia in an abstract language

[John Erling Blad]

Tried a couple of times to rewrite this, but it grows out of bound
anyhow. Seems like it has its own life.

There is a book from 2000 by Robert Dale and Ehud Reiter; Building
natural language generation systems  ISBN 978-0-521-02451-8

Wikibase items can be rebuilt as Plans from the type statement
(top-down) or as Constituents from the other statements (bottom-up).
The two models does not necessarily agree. This is although only the
overall document structure, and organizing of the data, and it leaves
out the really hard part – the language specific realization.

You can probably redefine Plans and Constituents as entities, I have
toyed around with them as Lua classes, and put them into Wikidata. The
easiest way to reuse them locally would be to use a lookup structure
for fully or partly canned text, and define rules for agreement and
inflection as part of these texts. Piecing together canned text is
hard, but easier than building full prose from the bottom. It is
possible to define a very low-level realization for some languages,
but that is a lot harder.

The idea for lookup of canned text is to use the text that covers most
of the available statements, but still such that most of the remaining
statements can also be covered. That is some kind of canned text might
not support a specific agreement rule, thus some other canned text can
not reference it and less coverage is achieved. For example the
direction to the sea can not be expressed in a canned text for Finnish
and then the distance can not reference the direction.

To get around this I prioritized Plans and Constituents, with those
having higher priority being put first. What a person is known for
should go in front of his other work. I ordered the Plans and
Constituents chronologically to maintain causality. This can also be
called sorting. Priority tend to influence plans, and order influence
constituents. Then there are grouping, which keeps some statements
together.  Length, width, height are typically a group.

A lake can be described with individual canned text for length, width,
and height, but those are given low priority. Then it an be made a
canned text for length and height, with somewhat higher priority. An
even higher priority can be given to a canned text for all three.
Given that all three statements are available then the composite
canned text for all of them will be used. If only some of them exist
then a lower priority canned text will be used.

Note that the book use "canned text" a little different.

Also note that the canned texts can be translated as ordinary message
strings. They can also be defined as a kind of entities in Wikidata.
As ordinary message strings they need additional data, but that comes
naturally as entities in Wikidata. My drodling put it inside each
Wikipedia, as it would be easier to reuse from Lua-modules. (And yes,
you can then override part of the ArticlePlaceholder to show the text
at the special page.)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Paladox via Wikitech-l]

 I’ve been working on a opt out (blacklist) in the plugin, see 
https://gerrit-review.googlesource.com/c/plugins/reviewers-by-blame/+/210812
On Friday, 18 January 2019, 09:39:55 GMT, Gergo Tisza 
 wrote:  
 
 On Thu, Jan 17, 2019 at 10:58 PM Giuseppe Lavagetto <
glavage...@wikimedia.org> wrote:

> While this gets improved, is there a way to opt-out from the feature
> individually or as a project?
>

Individually, no. On the project level, just set the max number of
reviewers added by the plugin to zero. (It seems that you need to use the
old Gerrit interface to see settings that come from plugins...)
___
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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Gergo Tisza]

On Thu, Jan 17, 2019 at 10:58 PM Giuseppe Lavagetto <
glavage...@wikimedia.org> wrote:

> While this gets improved, is there a way to opt-out from the feature
> individually or as a project?
>

Individually, no. On the project level, just set the max number of
reviewers added by the plugin to zero. (It seems that you need to use the
old Gerrit interface to see settings that come from plugins...)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit now automatically adds reviewers

[Jaime Crespo]

One member of my team sadly left. Now he is pinged every time I upload a
change, passively aggressive reminding him he used to work on this.

Don't get me wrong, I think this is great to get attention for new
contributors, to make sure it is moving forward, but I would suggest to be
able to opt-out of this.

On Fri, Jan 18, 2019 at 9:47 AM Thiemo Kreuz 
wrote:

> > […] automatically add reviewers to your changes based on who previously
> has committed changes to the file.
>
> I'm already overwhelmed with review requests. I'm also one of the
> latest contributors in sooo many files that I'm worried the plugin
> will add me to dozens per day from now on. This surprising addition
> makes me worry very much about my sanity and the usability of my inbox
> and Gerrit dashboards. Please, please, tune it down heavily.
>
> Until now, I had a process to find reviewers:
>
> 1. For planned changes, it's already obvious who needs to do the
> review: my team members. Often they don't even need to be added as
> reviewers, or don't want to, but use the "review" column on our
> Phabricator board. Automatically adding random *other* people is not
> only useless in this situation, it's counterproductive and frustrating
> for everybody involved. Other people should not waste their time with
> patches like this. When they do, it's frustrating for the one who was
> supposed to do the review, as well as for the "auto-reviewer". His
> review is not helpful and ultimately not appreciated.
>
> 2. For code cleanups in core and codebases my team does not own I open
> the list of merged patches on Gerrit to see if I can tell the names of
> one or two main contributors. Often, the list will contain nothing but
> the Translatewiki bot and a few people doing cross-codebase
> maintainance work. These highly active people should *not* be the
> first pick as potential reviewers for multiple reasons. Most
> importantly, just because someone is very productive it's not ok to
> expect him to accept even more workload. This is
> super-counterproductive and ultimately leads to people burning out.
> Secondly, just because someone updated, let's say, a call to a
> deprecated core function does not mean he is familiar with a codebase.
>
> 3. I look at the files my patch happens to touch in my PHPStorm IDE,
> enable the blame column that shows who touched a line last, and see if
> I can find the one who introduced the code I'm touching.
>
> All steps in this process involve *reading* the commit messages and
> considering what people did, when and why. This can't be automated.
>
> I do not entirely oppose the idea of adding reviewers automatically,
> as long as I (as a reviewer) have a chance to easily tell the
> difference between being added manually vs. automatically. For my
> sanity, I will most probably setup an email filter that auto-deletes
> all automated requests, and only look at these auto-reviews once a
> week via my Gerrit dashboard.
>
> Based on all these arguments this is what I, personally, find acceptable:
> * Make sure no emails are sent for being automatically added, or make
> sure it's possible to turn them off (without also killing the wanted
> emails about manually being added).
> * Make sure tool accounts like the library-upgrader or Translatewiki
> bot are never added as reviewers.
> * Never automatically add reviewers if there are other reviewers
> already. Most importantly, if people have been added via the reviewer
> bot already, that's more than enough.
> * Only add 2 reviewers. 2 people will more likely feel like a team. 3
> people are much more likely to all think "the other 2 will do it" and
> all ignore it.
> * Don't just pick the "most recent" contributor. That's most certainly
> not the person you want (probably one who fixed a typo, or updated a
> library). Implement an algorithm that can either understand who
> touched which places in the code, and assigns them to patches that
> happen to touch the same place again. Or go for an algorithm that (for
> example) analyzes the last year and picks the 2 people who did the
> most changes to a file in that time span.
>
> If more than one of these criteria is not met or not possible, the
> only solution I see is to make the plugin opt-in per codebase, not
> opt-out as of now (because you can't expect me to opt-out from
> literally a thousand codebases).
>
> Thank you for keeping my inbox sane.
>
> Best
> Thiemo
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jaime Crespo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit now automatically adds reviewers

[Thiemo Kreuz]

> […] automatically add reviewers to your changes based on who previously has 
> committed changes to the file.

I'm already overwhelmed with review requests. I'm also one of the
latest contributors in sooo many files that I'm worried the plugin
will add me to dozens per day from now on. This surprising addition
makes me worry very much about my sanity and the usability of my inbox
and Gerrit dashboards. Please, please, tune it down heavily.

Until now, I had a process to find reviewers:

1. For planned changes, it's already obvious who needs to do the
review: my team members. Often they don't even need to be added as
reviewers, or don't want to, but use the "review" column on our
Phabricator board. Automatically adding random *other* people is not
only useless in this situation, it's counterproductive and frustrating
for everybody involved. Other people should not waste their time with
patches like this. When they do, it's frustrating for the one who was
supposed to do the review, as well as for the "auto-reviewer". His
review is not helpful and ultimately not appreciated.

2. For code cleanups in core and codebases my team does not own I open
the list of merged patches on Gerrit to see if I can tell the names of
one or two main contributors. Often, the list will contain nothing but
the Translatewiki bot and a few people doing cross-codebase
maintainance work. These highly active people should *not* be the
first pick as potential reviewers for multiple reasons. Most
importantly, just because someone is very productive it's not ok to
expect him to accept even more workload. This is
super-counterproductive and ultimately leads to people burning out.
Secondly, just because someone updated, let's say, a call to a
deprecated core function does not mean he is familiar with a codebase.

3. I look at the files my patch happens to touch in my PHPStorm IDE,
enable the blame column that shows who touched a line last, and see if
I can find the one who introduced the code I'm touching.

All steps in this process involve *reading* the commit messages and
considering what people did, when and why. This can't be automated.

I do not entirely oppose the idea of adding reviewers automatically,
as long as I (as a reviewer) have a chance to easily tell the
difference between being added manually vs. automatically. For my
sanity, I will most probably setup an email filter that auto-deletes
all automated requests, and only look at these auto-reviews once a
week via my Gerrit dashboard.

Based on all these arguments this is what I, personally, find acceptable:
* Make sure no emails are sent for being automatically added, or make
sure it's possible to turn them off (without also killing the wanted
emails about manually being added).
* Make sure tool accounts like the library-upgrader or Translatewiki
bot are never added as reviewers.
* Never automatically add reviewers if there are other reviewers
already. Most importantly, if people have been added via the reviewer
bot already, that's more than enough.
* Only add 2 reviewers. 2 people will more likely feel like a team. 3
people are much more likely to all think "the other 2 will do it" and
all ignore it.
* Don't just pick the "most recent" contributor. That's most certainly
not the person you want (probably one who fixed a typo, or updated a
library). Implement an algorithm that can either understand who
touched which places in the code, and assigns them to patches that
happen to touch the same place again. Or go for an algorithm that (for
example) analyzes the last year and picks the 2 people who did the
most changes to a file in that time span.

If more than one of these criteria is not met or not possible, the
only solution I see is to make the plugin opt-in per codebase, not
opt-out as of now (because you can't expect me to opt-out from
literally a thousand codebases).

Thank you for keeping my inbox sane.

Best
Thiemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l