[Wikitech-l] Thank you Tuesday

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It's still Tuesday in my timezone, so here's this week's thread.
Noticed something neat or cool that someone did? Or is someone just
being awesome in general? Say thanks!

* Thanks to Krinkle and Krenair for cleaning up user JavaScript across
Wikimedia wikis.
* Thanks to MusikAnimal for figuring out why signatures are typed
using four tiles ()[1].
* Thanks to Jjanes for helping to maintain Postgres support in MediaWiki
.
* And thanks to Quiddity for always staying positive. :-)

[1] https://twitter.com/MagnusManske/status/1083507467802365952

- -- Legoktm
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAlxIHNkACgkQ8QX4EBsF
JpuDaQ//RLA/RsSGjU4sAKjJXNcE5d2Z+vUJCsHqjAYYC4K7xgdBQwYrIn0fXjUd
spuvRuJ7mi2kefDMEFQDX9r8odONzoyq0yyCaaq1+h6BCSVLcxSq/F1Pxuj7hZrz
lyjrtnVL39k13zGHHDzyVzQIig0ng91G2a5CuGrit8xaE25R1KGMgonWiWshn/B7
JOx2UYB0KHzBjfu388Jk9CgmuNiTVo2w5bfp1W+T0xmGpWoaodTCU3aUrRASjqeQ
A7OqUm6vRHvKrQ65iZuW14S28+OsQzJJWbd9+kjWDvnyf2oLzfgsxnzINvY0dWjC
d8FJcWjDyK3FKGI0FDLxaRiohFJlmajsvYhH9kuD1JuuxztYE/Qws5HkvhBD+FIw
oS0g6D/7avFhAC19ar0eH25VRvav1hr4cr63WXkdUUuaXF4pgEcgIv3ARmm1YF5g
8EsZS4UevBVv8TiNZOKjW1XJgMzFzkXdKuZdTfHWv2sZgdr5Wo4mo8WqEjJJJMcN
2vHUi/gSPz7PI1RGmve4JkFKHq/vThma53U8n5k9tfAKynhfqObo5vL7vXet8hZ/
eoN/58ruo/5Vat/4lxpQSV5ck1XxOXcPPYJUlhqUdOKNmTenqZYGxkk9uxjh3OOB
uiyE7emG89yC4wXqkosSTURCzsbiNqzdTQ1AS9cb3hE9nLlgQfQ=
=msV9
-END PGP SIGNATURE-

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

[Wikitech-l] Discovery Weekly Update for the week starting 2019-01-14

[Chris Koerner]

Hello,
This is the weekly update from the Search Platform team for the week
starting 2019-01-14.

As always, feedback and questions welcome.

== Discussions ==

=== Search ===
* Trey updated TextCat with models for detecting Russian typed on an
English keyboard and vice-versa, and UTF-8 Russian text improperly
encoded as Windows-1251, [0] as a precursor to providing
wrong-keyboard/encoding detection and suggestion. [1]
* Erik and the team did a lot of work on an epic ticket (with several
sub tasks) to explore and figure out next steps in  using user click
data to tune Wikidata search parameters [2] and [3]. The team will
ship the newly tuned wbsearchentities profile for en soon with de, fr,
es afterward.
* The team also had lots of discussions and exploration on how to
transform Wikidata autocomplete click logs into a useful dataset. They
are now transformed: Relevance Forge now has a utility for taking in
the Wikidata completion search logs and tuning the parameters of
search based on those logs. [4]
* David fixed a minor regression where search request failures when
offset+limit is out of bounds (cirrussearch-backend-error) [5]
* Mathew discovered that the required metrics have been exposed by the
prometheus exporter but they are displaying and fixed the issue with
help from David and Gehel [6]
* David reconfigured the ElasticSearch crosscluster on production
search servers to have persistent configs [7]

=== WDQS ===
* Stas & Guillaume finished moving categories namespace into a
separate Blazegraph instance [8]

== Did you know? ==
English text, like many others, is written left-to-right (LTR), but
some languages—most notably Arabic, Hebrew, Persian, and Urdu, but
also many others [9]—are written right-to-left (RTL). To handle
different writing directions—especially in mixed LTR and RTL
texts—Unicode classifies characters as having "strong", "weak", or
"neutral" directionality. Strong characters definitely go in a
particular direction, like ABC or אבג. Weak characters have a "vague"
directionality, but can be changed in context, mostly numbers. Neutral
characters pick up their directionality from context, like punctuation
and whitespace characters used across scripts.

Mirrored characters change the way they display based on context. For
example "A>B>C" and "א>ב>ג" both only have the greater than character
(>) in them, but, if you are reading this somewhere that follows the
Unicode bidirectional algorithm, the ones between Latin letters point
to the right and those between Hebrew letters point to the left.

The algorithms are complicated [10], and when they don't work, there
are explicit characters that indicate things like "text should flow
left to right from here". The explicit formatting characters have the
most potential to cause trouble for search because they are usually
invisible, and you can pick one up without realizing it. For example,
when copying an Arabic word from a page in English, or a French word
from a page in Hebrew, the word that is "the other way around" from
the main text might have one of these marks at the beginning or end of
it. Fortunately, we can usually identify them and strip them out.

Finally, there are some scripts that have been written in other
interesting directions. Vertical text includes Chinese, Japanese, and
Korean, [11] and Mongolian. [12]. Hanunó'o [13] and Ogham [14] were
written bottom-to-top! My [Trey's] favorite "direction" is
"boustrophedon," [15] which means "like an ox ploughs" and alternates
left-to-right and right-to-left, and was used particularly in old
manuscripts and inscriptions in may writing systems. Why jump from one
side of the page to the other when you can just curve around where you
are or flip to mirrored letters and keep going?!

[0] https://phabricator.wikimedia.org/T213931
[1] https://phabricator.wikimedia.org/T138958
[2] https://phabricator.wikimedia.org/T193701
[3] https://phabricator.wikimedia.org/T213105
[4] https://phabricator.wikimedia.org/T205111
[5] https://phabricator.wikimedia.org/T213745
[6] https://phabricator.wikimedia.org/T210592
[7] https://phabricator.wikimedia.org/T213150
[8] https://phabricator.wikimedia.org/T213212
[9] https://en.wikipedia.org/wiki/Right-to-left#List_of_RTL_scripts
[10] https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
[11] 
https://en.wikipedia.org/wiki/Horizontal_and_vertical_writing_in_East_Asian_scripts
[12] https://en.wikipedia.org/wiki/Mongolian_script
[13] https://en.wikipedia.org/wiki/Hanun%C3%B3%27o_alphabet
[14] https://en.wikipedia.org/wiki/Ogham
[15] https://en.wikipedia.org/wiki/Boustrophedon



Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1]

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

[Tyler Cipriani]

Hi all!

This plugin has been removed entirely from Wikimedia Gerrit[0]. I know 
of no one who intended to experiment with the plugin in its current form 
so it is now removed.


I have created a task to track suggestions for this plugin's 
improvement[1]. This task's scope is to track suggestions for 
improvements to the reviewers-by-blame plugin so they are not lost in 
this thread. Implementation details about individual suggestions should 
(likely) become seperate tasks.


Any discussion about what is needed to re-enable this plugin for 
Wikimedia's Gerrit is a different discussion for another task and time. 
We won't re-enable this plugin without notice or without further 
discussion.



On 19-01-21 18:20:13, Paladox via Wikitech-l wrote:
FYI i have a working prototype working ("Suggest Reviewer") button.


On Monday, 21 January 2019, 16:32:35 GMT, Paladox via Wikitech-l 
 wrote:

I’m currently working on addressing all the feedback as fast as I can.
I honestly think this extension is great especially for new users, who
do not know they need reviewers or who would review there change.
Granted this extension has some problems hence why feature requests
were filed against the extension.


+1 to what Niharika and other have said: thank you for all your work on 
Gerrit, Paladox!


You have made maintaining and keeping Gerrit secure easier for me 
personally.


Thanks all for your thoughts on this thread, and thank you in advance for 
ensuring the task for suggestions for improvement is accurate.


-- Tyler

[0]. 
[1]. 


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

[Antoine Musso]

On 18/01/2019 23:12, 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


Hello Pine

We had the Gerrit reviewers-by-blame installed a while ago although it 
was not functional. Tyler, Gergo and I have been talking about that idea 
for quite a while and felt like it was a good idea to get patches reviewed.


On a quick though, if one authored some code, most probably that person 
knows the code and thus would qualify as a reviewers. For the few code I 
wrote from scratch, I am certainly interested in being added automatically.


Anyway, we went with upgrading the Gerrit plugin. I even wrote a blog 
post to explain a bit of the feature and other ways to find reviewers:

https://phabricator.wikimedia.org/phame/post/view/139/

I don't write blogs that often. If I do it is because I am excited about 
some feature which I firmly believe to be a general improvement.  I have 
been naive?  Yes surely.  Did we miss evaluating potential side effects? 
 For sure.


Then one as to take in perspective the cost of trying and reverting 
versus spending ages and months on a project only to dish it out because 
that is not what the customer wanted.  I, and several, choose the first 
path: quick cheap experiment with limited casualties. A benefit is that 
this thread gave a lot of exposure to the feature and gathered a lot of 
constructive feedback.  One can then easily conclude that the plugin is 
not smart enough and fails to spot the proper reviewers.


The plugin does not add reviewers any more (it defaults to add 0 
reviewers), and I guess we will just uninstall it entirely.



As for new features for Gerrit or Phabricator or CI. There is no due 
process established. We just f***ing do it, given we promptly rollback 
when we screw up which is thankfully rather rare.  Else we iterate and 
refine the feature until it is deemed stable.


That is how we maintain our infrastructure, not by having four hours 
meetings week after weeks with no deployment in between, not by having 
cross teams agreement, nor five level of political hierarchy drama.  We 
certainly had a few outages here and there, but given the very few 
people working on those parts and the number of modifications we do on a 
weekly basis, I think it is overall rather stable.



I am not willing to start a flame war, but I do not think the English 
Wikipedia community is a good example of an healthy one. The huge amount 
of process and policies makes it a challenge to have edits retained, it 
is partly what made me stop editing entirely.



In short, Pine, please assume good faith 8-]


--
Antoine "hashar" Musso
{^-^}


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

Re: [Wikitech-l] Unsubscription Request

[Lucas Werkmeister]

There’s an “unsubscribe” section on this link (which should be in the
footer of each email, though your client may hide it or make it less
prominent, not sure):
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Cheers,
Lucas

Am Di., 22. Jan. 2019 um 14:18 Uhr schrieb Ayushi Jain via Wikitech-l <
wikitech-l@lists.wikimedia.org>:

> I want to unsubscribe. Can't find any link on the emails sent by you.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Full Stack Developer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Unsubscription Request

[Ayushi Jain via Wikitech-l]

I want to unsubscribe. Can't find any link on the emails sent by you.
___
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

[Cormac Parle]

+1 to Niharika - the initial iteration caused some inconvenience, but I expect 
subsequent iterations to be useful. Thank you Paladox!





> On 22 Jan 2019, at 13:09, Niharika Kohli  wrote:
> 
> On Tue, Jan 22, 2019 at 6:12 PM Paladox via Wikitech-l <
> wikitech-l@lists.wikimedia.org> wrote:
> 
>> What your saying is making me think I’m wasting my time on improving this
>> extension.
>> Also other users that have spoken to me have thought this extension is
>> great but could do with improvements which I am doing. We need to think of
>> new users and how to improve there experence. The task was opened for a
>> long while yet no one commented on it.
>> I agree with legoktm feedback.
>> “A process that annoys people based on nothing but the fact that
>> theyhappened to be the last one touching a file *is* fundamentally broken.”
>> yes hence why I’ve been making improvements by adding a button which is
>> better then nothing right?
>> As chad mentions it has no idea what is a typo fix compared to other
>> things as it’s not A.I.
>> 
> 
> Thanks for working on this, Paladox. I think this can be a really useful
> feature for newcomers and experienced developers alike, if implemented
> well. I look forward to seeing it in action.
> 
> 
>>On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz <
>> thiemo.kr...@wikimedia.de> wrote:
>> 
>>> Fundamentally broken sounds like a bit of a stretch.
>> 
>> A process that annoys people based on nothing but the fact that they
>> happened to be the last one touching a file *is* fundamentally broken.
>> This is not how anyone should look for reviewers, neither manually nor
>> automatically.
>> 
>> Here is a thought experiment: We could send review requests to the
>> *least* active users that are still around, but *never* touched a
>> file. The positive effects of such an approach include:
>> * More people get familiar with the code.
>> * Knowledge gets spread more evenly.
>> * Bottlenecks and bus factors get reduced.
>> * These people probably have more time.
>> * Review requests are spread more evenly.
>> * Workload is spread more evenly.
>> 
>> Still sounds like a bad idea? Sure, because it is. Now tell me: How is
>> it more clever to do the *opposite* and dump review requests on people
>> that have to much workload already?
>> 
>> At this point I don't care any more if we are talking about a fully
>> automated process or a suggest button. Both are targeting the wrong
>> people.
>> 
>>> it was probably working quite well for our less-trafficked repositories.
>> 
>> What is the difference between being the last one fixing a typo in a
>> low-traffic vs. high-traffic repository? In both cases it's the wrong
>> person.
>> 
>> Thiemo
>> 
>> ___
>> 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
> 
> 
> 
> -- 
> Niharika
> Product Manager
> Community Tech
> 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

[Niharika Kohli]

On Tue, Jan 22, 2019 at 6:12 PM Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

>  What your saying is making me think I’m wasting my time on improving this
> extension.
> Also other users that have spoken to me have thought this extension is
> great but could do with improvements which I am doing. We need to think of
> new users and how to improve there experence. The task was opened for a
> long while yet no one commented on it.
> I agree with legoktm feedback.
> “A process that annoys people based on nothing but the fact that
> theyhappened to be the last one touching a file *is* fundamentally broken.”
> yes hence why I’ve been making improvements by adding a button which is
> better then nothing right?
> As chad mentions it has no idea what is a typo fix compared to other
> things as it’s not A.I.
>

Thanks for working on this, Paladox. I think this can be a really useful
feature for newcomers and experienced developers alike, if implemented
well. I look forward to seeing it in action.


> On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz <
> thiemo.kr...@wikimedia.de> wrote:
>
>  > Fundamentally broken sounds like a bit of a stretch.
>
> A process that annoys people based on nothing but the fact that they
> happened to be the last one touching a file *is* fundamentally broken.
> This is not how anyone should look for reviewers, neither manually nor
> automatically.
>
> Here is a thought experiment: We could send review requests to the
> *least* active users that are still around, but *never* touched a
> file. The positive effects of such an approach include:
> * More people get familiar with the code.
> * Knowledge gets spread more evenly.
> * Bottlenecks and bus factors get reduced.
> * These people probably have more time.
> * Review requests are spread more evenly.
> * Workload is spread more evenly.
>
> Still sounds like a bad idea? Sure, because it is. Now tell me: How is
> it more clever to do the *opposite* and dump review requests on people
> that have to much workload already?
>
> At this point I don't care any more if we are talking about a fully
> automated process or a suggest button. Both are targeting the wrong
> people.
>
> > it was probably working quite well for our less-trafficked repositories.
>
> What is the difference between being the last one fixing a typo in a
> low-traffic vs. high-traffic repository? In both cases it's the wrong
> person.
>
> Thiemo
>
> ___
> 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



-- 
Niharika
Product Manager
Community Tech
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

[Thiemo Kreuz]

> […] "people who have worked on this code before" is an excellent metric by 
> which to find people to review your code.

Sure. But this is neither what I wrote, nor what the plugin does, nor
what can be done programmatically in the first place, as you
conveniently pointed out yourself:

> […] we can't possibly know what was a one-line typofix and what was a one 
> line that saved us 50% of execution time on all pages. At least not 
> programmatically.

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

[Physikerwelt]

I suggest discussing the implementation details on phabricator.
Moreover, I second Lucas point on the tone.
physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

On Tue, Jan 22, 2019 at 1:43 PM Lucas Werkmeister
 wrote:
>
> Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad :
>
> > Dumb straw man.
> >
>
> can we avoid this tone? thanks
>
> Who said these people have too much workload?
>
>
> Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
> about his own workload?
>
> The blame attribution has zero insight into how
> > busy someone is.
> >
>
> Correct, which is why it’s a bad idea to let it run loose and add people
> who are already busy enough as reviewers.
>
>
> > If it's a low-traffic repository there's likely to be fewer overall
> > contributors.
> > Fewer contributors increases the likelihood of people being qualified to
> > review--whereas a high-traffic repo is more likely to have drive-by
> > contributor less capable.
> >
>
> Well, many drive-by contributions are tree-wide: they are applied to a
> large set of repositories collectively, e. g. all Wikimedia-deployed
> extensions or even all repositories. If a repository has generally low
> traffic, then these tree-wide drive-by contributions will make up a larger
> ratio of its commits than in repositories with more repository-specific
> commits.
>
> I’m not sure if I phrased this well, but if repository A has 1000 specific
> commits and 10 drive-by commits, and repository B has 20 specific commits
> and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
> all commits in repository B but less than .1% in repository A.
>
>
> > And if it's just one-line typofixing it'd be ideal to exclude those from
> > the
> > blame list--but we can't possibly know what was a one-line typofix and
> > what was a one line that saved us 50% of execution time on all pages.
> > At least not programmatically.
> >
>
> True to some extent, but then we should err on the side of not adding the
> reviewer, no? Otherwise we run the risk of overwhelming them with changes
> they’re not even qualified to review, even if they had the time.
>
>
> > Honestly, if you think "people who've edited the code in the past" are a
> > poor
> > person to ask for review then you do not understand how code review works.
> >
>
> Suggesting that Thiemo doesn’t understand how code review works is… bold,
> in my opinion, let’s put it that way. May I point out that he’s one of the
> top +2ers across all MediaWiki extensions
> ?
>
> Cheers,
> Lucas
>
>
> --
> Lucas Werkmeister
> Full Stack Developer
>
> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> https://wikimedia.de
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us to achieve our vision!
> https://spenden.wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/029/42207.
> ___
> 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

[Lucas Werkmeister]

Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad :

> Dumb straw man.
>

can we avoid this tone? thanks

Who said these people have too much workload?


Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
about his own workload?

The blame attribution has zero insight into how
> busy someone is.
>

Correct, which is why it’s a bad idea to let it run loose and add people
who are already busy enough as reviewers.


> If it's a low-traffic repository there's likely to be fewer overall
> contributors.
> Fewer contributors increases the likelihood of people being qualified to
> review--whereas a high-traffic repo is more likely to have drive-by
> contributor less capable.
>

Well, many drive-by contributions are tree-wide: they are applied to a
large set of repositories collectively, e. g. all Wikimedia-deployed
extensions or even all repositories. If a repository has generally low
traffic, then these tree-wide drive-by contributions will make up a larger
ratio of its commits than in repositories with more repository-specific
commits.

I’m not sure if I phrased this well, but if repository A has 1000 specific
commits and 10 drive-by commits, and repository B has 20 specific commits
and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
all commits in repository B but less than .1% in repository A.


> And if it's just one-line typofixing it'd be ideal to exclude those from
> the
> blame list--but we can't possibly know what was a one-line typofix and
> what was a one line that saved us 50% of execution time on all pages.
> At least not programmatically.
>

True to some extent, but then we should err on the side of not adding the
reviewer, no? Otherwise we run the risk of overwhelming them with changes
they’re not even qualified to review, even if they had the time.


> Honestly, if you think "people who've edited the code in the past" are a
> poor
> person to ask for review then you do not understand how code review works.
>

Suggesting that Thiemo doesn’t understand how code review works is… bold,
in my opinion, let’s put it that way. May I point out that he’s one of the
top +2ers across all MediaWiki extensions
?

Cheers,
Lucas


-- 
Lucas Werkmeister
Full Stack Developer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
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]

 What your saying is making me think I’m wasting my time on improving this 
extension.
Also other users that have spoken to me have thought this extension is great 
but could do with improvements which I am doing. We need to think of new users 
and how to improve there experence. The task was opened for a long while yet no 
one commented on it.
I agree with legoktm feedback.
“A process that annoys people based on nothing but the fact that theyhappened 
to be the last one touching a file *is* fundamentally broken.”
yes hence why I’ve been making improvements by adding a button which is better 
then nothing right?
As chad mentions it has no idea what is a typo fix compared to other things as 
it’s not A.I.

On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz 
 wrote:  
 
 > Fundamentally broken sounds like a bit of a stretch.

A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.

Here is a thought experiment: We could send review requests to the
*least* active users that are still around, but *never* touched a
file. The positive effects of such an approach include:
* More people get familiar with the code.
* Knowledge gets spread more evenly.
* Bottlenecks and bus factors get reduced.
* These people probably have more time.
* Review requests are spread more evenly.
* Workload is spread more evenly.

Still sounds like a bad idea? Sure, because it is. Now tell me: How is
it more clever to do the *opposite* and dump review requests on people
that have to much workload already?

At this point I don't care any more if we are talking about a fully
automated process or a suggest button. Both are targeting the wrong
people.

> it was probably working quite well for our less-trafficked repositories.

What is the difference between being the last one fixing a typo in a
low-traffic vs. high-traffic repository? In both cases it's the wrong
person.

Thiemo

___
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

[Chad]

On Tue, Jan 22, 2019 at 4:05 AM Thiemo Kreuz 
wrote:

> > Fundamentally broken sounds like a bit of a stretch.
>
> A process that annoys people based on nothing but the fact that they
> happened to be the last one touching a file *is* fundamentally broken.
> This is not how anyone should look for reviewers, neither manually nor
> automatically.


It isn't? I figured "people who have worked on this code before" is an
excellent metric by which to find people to review your code. It's certainly
who I'd look to help me if I didn't just _know_ who to ask.


>
>
Here is a thought experiment: We could send review requests to the
> *least* active users that are still around, but *never* touched a
> file. The positive effects of such an approach include:
> * More people get familiar with the code.
> * Knowledge gets spread more evenly.
> * Bottlenecks and bus factors get reduced.
> * These people probably have more time.
> * Review requests are spread more evenly.
> * Workload is spread more evenly.
>
> Still sounds like a bad idea? Sure, because it is.


Dumb straw man.


> Now tell me: How is
> it more clever to do the *opposite* and dump review requests on people
> that have to much workload already?
>

Who said these people have too much workload? Just because they've
made a commit before? The blame attribution has zero insight into how
busy someone is.


> At this point I don't care any more if we are talking about a fully
> automated process or a suggest button. Both are targeting the wrong
> people.


>
> it was probably working quite well for our less-trafficked repositories.
>
> What is the difference between being the last one fixing a typo in a
> low-traffic vs. high-traffic repository? In both cases it's the wrong
> person.
>

If it's a low-traffic repository there's likely to be fewer overall
contributors.
Fewer contributors increases the likelihood of people being qualified to
review--whereas a high-traffic repo is more likely to have drive-by
contributor less capable.

And if it's just one-line typofixing it'd be ideal to exclude those from the
blame list--but we can't possibly know what was a one-line typofix and
what was a one line that saved us 50% of execution time on all pages.
At least not programmatically.

Honestly, if you think "people who've edited the code in the past" are a
poor
person to ask for review then you do not understand how code review works.

-Chad
___
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]

> Fundamentally broken sounds like a bit of a stretch.

A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.

Here is a thought experiment: We could send review requests to the
*least* active users that are still around, but *never* touched a
file. The positive effects of such an approach include:
* More people get familiar with the code.
* Knowledge gets spread more evenly.
* Bottlenecks and bus factors get reduced.
* These people probably have more time.
* Review requests are spread more evenly.
* Workload is spread more evenly.

Still sounds like a bad idea? Sure, because it is. Now tell me: How is
it more clever to do the *opposite* and dump review requests on people
that have to much workload already?

At this point I don't care any more if we are talking about a fully
automated process or a suggest button. Both are targeting the wrong
people.

> it was probably working quite well for our less-trafficked repositories.

What is the difference between being the last one fixing a typo in a
low-traffic vs. high-traffic repository? In both cases it's the wrong
person.

Thiemo

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

Re: [Wikitech-l] UserMerge extension on Wikimedia sites

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 1/22/19 12:24 AM, Amir E. Aharoni wrote:
> Yes, it's installed, but it doesn't seem to be actually used. The
> English Wikivoyage has a bunch of log entries of its usage, the
> last in 2015. Other Wikimedia sites have very few entries, or none
> at all.
> 
> My guess, and please do correct me if I'm wrong, is that it was
> used on Wikitravel or Wikivoyage, and that it is still installed
> for backwards compatibility so as not to break the logs or the
> global user accounts data, but it is not completely compatible with
> other Wikimedia sites, so it can't be used either.

It was used right after Wikivoyage joined Wikimedia to reconcile their
accounts with SUL. It was mostly luck that nothing bad happened, as
well as the fact Wikivoyage was pretty small (relatively speaking) so
it didn't run into the performance problems that exist. There was an
attempt during/after SUL finalization to create a global user merge
tool, but it never worked out in reality.

> If my assessment is correct, then it should be marked as "Legacy"
> on translatewiki. This doesn't mean it will be removed; it will
> remain available for translation. It just means that translators
> who want to focus on completing the translation of extensions that
> are used on Wikimedia sites will know that it's not used much, and
> it's not a high priority to translate it, and will translate
> something more important first.

This seems appropriate, though as Marco mentioned, we should probably
just undeploy it from Wikimedia now (figuring out something about log
entries).

- -- Legoktm
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAlxG5isACgkQ8QX4EBsF
Jps8iBAAjq7oMtGvIxTYOwsm3pgIaxkukZedgvHeGDeYMUgqXG/ancqgxGh6FiZB
15duV/evbGntHB9+Zj0j9Sbah/ub50Toawk7kmwsvDun/e0uo/jWHUibAQgIxBsn
6qj0oVyRZy+p0FNMYIOdGMdGHYzupAntOBFt6MUB3MEbLsXGNTmmzM+c5+cyQuHq
bjBINDKV6PISZzn/AIoNgjzj7x92q9duvEyK8movkv4cijH7DlBS+IYR+6yy+t10
oxCIMJ1SObnCUNf+rWfTaM0vs+pNdqfd4kWHLqc+s35xVJV5eLT6jtR5KKbpSffc
UEk9I8lj79Ul0a0jv+xChNt+CId6Z+fma50NMgDV43eU8eYihujEwiRbDwvSA3k+
HRUkq/LxKU6P2zi+whSLdCwEyiq57NMRpLCgTmpGY9VD6sZkYrHH8bmqvUlvirfQ
L4cSk6Ijqqrg6Ei7Z6kIfOTOPKNAHvgBuZ5Pzud/B5jBkth2A3z0pkml7uba02/2
+xM5hAajQIWOQOi/KyHXY/8+DZAPnUySpacMiFBmZf4IdKDMCg8mLJkmu40sWofV
zvegaplxUyZPCVjjQVkEH1DocxjHVG6TYJKlHx5uqd67o0qj5YtVTByvgiP/HkKV
oKA3fZURvNwAUgU/TnRH7vXb0DsEEJjjTA25GZzruYK672iAH8o=
=D376
-END PGP SIGNATURE-

___
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

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 1/18/19 1:11 AM, Jaime Crespo wrote:
> 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.

While exacerbated by the plugin, I think this is a problem in general,
when someone (typically staff) leaves the movement, and others are
unaware and continue to request reviews from them (and likely a
bouncing mailbox :/).

In these cases it would be nice if those people could set their Gerrit
status[1] to something indicating that they won't be reviewing code
anymore so others don't add them as reviewers.

[1] Simetrical has theirs set to "Inactive until April" for example:
https://screenshots.firefox.com/JWmxdIdXtGaQ8EHW/gerrit.wikimedia.org

- -- Legoktm
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAlxG3Z4ACgkQ8QX4EBsF
Jpvelg/+PoGQ42VRh+JYSIGf0gbzIIyE+K512KDLwH3gDt7RwtRHEANtL3oPjtcl
BmmRYl27BcZDoqhAcU4MKTYZgKlQAKL0jPwKXJzgi2LZMBF65GfKjeHxFWIcyjm/
KbIfvqtJ0DV+vYICJVyP0Iyj8JSj8bG+yQmkdbTKgsGgG2CqMgDLZWt261IxJ4i2
oxZmrVxE6QiNRcmFbPuVsbVE2gD9RofiAZioI00I4NLkU9E3ONnwF8cY+L7VHtLp
1WNtWRm5Oeys/ltK45RjjBKCYeUeti2rtvH6mY2Sa8oSct/uY3QoX5k7SmKxyFJv
AKJYPtrvQ9umBJgmJnnLeD5DOdOIUvqcR+ST1xepgJGYHnSvThpqMUVKq1sjP6Vw
K8mVGu7o1DzOEHB9o3fwI4ChaAwO+Ng7kgk5d5ZRLscaXgDPN5X3BuI5Wbd4iJjy
RATO6OHLOEJFeBaLOeEMLRG6xfShaRNKB8OvUlAF7ireyk8/SmUzhzmz00dDEcR9
P/I6LMFScKxDYwMfLw8hzl12PGTHst2O9FV6F5l2lpbEhBYnO32uc7Y/juIp/3tg
SNW+juCRkhXrYOnQMltP/nGGeSD/0Mtrj76eTfKp0e6DzdWk03C7DXSXN4rH1fJ8
1tIDjsqDGsWX++i99kNgM4vJWB3sTqv6bL+bPt1A7vvs8fj61m8=
=KKBa
-END 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

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 1/18/19 6:11 AM, Tyler Cipriani wrote:
> 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.

I'm happy to volunteer any of the projects I help maintain as a guinea
pig once modifications to the plugin are ready for wider testing.

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

IMO, the main place where the Reviewer-Bot falls short is that it
relies on a hardcoded list of file paths that often change and then
requires manual intervention. Using blame is nice in that it's automatic
.

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

I've spoken to plenty people that complain that their patch was never
merged, and after looking, it had no reviewers assigned :-(

My suggestions for the plugin:
* Require some manual interaction by the patch author, similar to
GitHub (I believe Paladox is already working on this)
* Some account-level opt-out for bots, people who have left the
movement, etc.
* Don't suggest people that have already been manually removed from
the patch
* Only suggest people that have been active on Gerrit (or maybe limit
it to that repo) in the past X months/years.
** For repositories that have no active development but a maintainer
who still checks email, using a time-based check might not work. In a
past experiment I looked at the last 100 merged patches.
* If feasible, introduce some kind of marking (hashtag? topic?) that
can be used in mass cleanup style commits so that they are ignored by
the blame so drive by contributors aren't suggested as reviewers. I
currently have a mail filter with a few different Gerrit topics (e.g.
bump-dev-deps) to separate those review requests from other ones.

Thanks to those that are working on this.
- -- Legoktm
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAlxG2x8ACgkQ8QX4EBsF
JptONA//S4Ea2Fxsmm7ZrWs/yb+qSuYQQuAUnTnSUdCY2+rCcIsnhLvHaF/eGdFE
JEsjiq4bHpb58FG+oDvB3TAJxhrhs3Vi+6reZVONzKNS/cki//FGGiBjLqmd/5a6
8LVwswOUsJgiMig45ZL48nrpB9GorxJIj8PxhvzE7IuBWTdwUaiW1Wt0n2/6CNgj
Rj9mMv+cPVhy19itzQ5pwwxmeA/wRzqvnPBUFgGdigrXivtQhzw5tFg/KXiO/kLc
90Wb2ubZpHNvW4EN+TYDMacy9Y+kuluvkynK8fc40xQHf4eS98W3bTnihO6NFL+j
c2LqEVLrGxOHa70xt6K2poJ2JbgCYGlyzYLbxU9ug0gWh4HT+Fwo/keNLi41WyJC
UibnObplCBIna0aZ2xsgoo6F1rS5UUb/3TAyTR8Lx8ceeoteWNtiR/rdFOLR0Br8
vUyWkFJ9sESW75UdeiU3CpHoBisK9lKRa+zdhjAqwwUKoOZDdjq7iKfggK2Yl5Hp
1iF8ARDmtiTN1XgaN64vT7VXpv5+RrWXHFki9WCapWhSP3PCovBp0fTB1MMhAZq3
N3kACRPJR1NrrVw/ZUdCm85cDbFdueNp7Pl2eV5C5Bqj4nyaL89t0L2Uinz3snYI
Y3lfFRB8I74CamwyTAzTQAILMMXVj7uqCvR0j6lTix+czmMKpao=
=QEZv
-END 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

[Gergo Tisza]

This discussion could do with less theatrics IMO.
___
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]

 No, I added in a config so that it would disable automatically adding 
reviewers instead relying on users to press “Suggest Reviewers” button.
On Tuesday, 22 January 2019, 08:11:23 GMT, Thiemo Kreuz 
 wrote:  
 
 > […] im adding that functionality to reviewers-by-blame.

I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea to turn this feature set on again? My
impression was more that all the ideas that have been shared in this
email thread describe an *entirely* different approach, following
entirely different ideas, with an entirely different UI, and entirely
different setup. What's the point of stuffing this into the same,
fundamentally broken codebase?

Sysops, please, for our sanity, do not let anybody enable this toxic
plugin again.

Best
Thiemo

___
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] UserMerge extension on Wikimedia sites

[Amir E. Aharoni]

Yes, it's installed, but it doesn't seem to be actually used. The English
Wikivoyage has a bunch of log entries of its usage, the last in 2015. Other
Wikimedia sites have very few entries, or none at all.

My guess, and please do correct me if I'm wrong, is that it was used on
Wikitravel or Wikivoyage, and that it is still installed for backwards
compatibility so as not to break the logs or the global user accounts data,
but it is not completely compatible with other Wikimedia sites, so it can't
be used either.

If my assessment is correct, then it should be marked as "Legacy" on
translatewiki. This doesn't mean it will be removed; it will remain
available for translation. It just means that translators who want to focus
on completing the translation of extensions that are used on Wikimedia
sites will know that it's not used much, and it's not a high priority to
translate it, and will translate something more important first.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


‫בתאריך יום ג׳, 22 בינו׳ 2019 ב-10:15 מאת ‪Thiemo Kreuz‬‏ <‪
thiemo.kr...@wikimedia.de‬‏>:‬

> > Is the UserMerge extension actually used on Wikimedia sites?
>
> I don't know if people *use* it, but according to
> https://wikiapiary.com/wiki/Extension:UserMerge it is installed on
> more than a thousand wikis, including all Wikimedia wikis.
>
> Best
> Thiemo
>
> ___
> 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

[Chad]

Fundamentally broken sounds like a bit of a stretch.

In fact, it was probably working quite well for our less-trafficked
repositories. But the issues identified must be fixed and decent file
exclusion rules written before it goes back on for the active ones.

-Chad

On Jan 22, 2019 12:11 AM, "Thiemo Kreuz"  wrote:

> […] im adding that functionality to reviewers-by-blame.

I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea to turn this feature set on again? My
impression was more that all the ideas that have been shared in this
email thread describe an *entirely* different approach, following
entirely different ideas, with an entirely different UI, and entirely
different setup. What's the point of stuffing this into the same,
fundamentally broken codebase?

Sysops, please, for our sanity, do not let anybody enable this toxic
plugin again.


Best
Thiemo

___
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] UserMerge extension on Wikimedia sites

[Vi to]

AFAIR it was at very risk of breaking the Internet, so it went into a limbo
of being installed but never used.

Vito

Il giorno mar 22 gen 2019 alle ore 08:46 Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> ha scritto:

> Hi,
>
> Is the UserMerge extension actually used on Wikimedia sites?
>
> As far as I can see, it is only installed on Wikivoyage, and the last log
> entries of its usage are from 2015. However, it's possible that I'm missing
> something.
>
> The reason I'm asking is that I'd love to know how to configure it best in
> translatewiki. If it's not actually used on Wikimedia sites or developed
> significantly, then it should be filed under "Legacy".
>
> Thanks! :)
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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] UserMerge extension on Wikimedia sites

[MA]

Hello,

UserMerge as it is right now is unusable for Wikimedia sites, and thus no
user (bureaucrats, etc.) is allowed to use it. The extension is now up for
a Code Stewarship Review to decide what to do with it <
https://phabricator.wikimedia.org/T204747>, and I am proposing to undeploy
the extension from WMF sites given those issues. That said, the extension
might work for translatewiki where there are no CentralAuth, FlaggedRevs
and many other features which tend to be problematic with UserMerge, as far
as I was told.

Regards, M.

El El mar, 22 ene 2019 a las 8:46, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> escribió:

> Hi,
>
> Is the UserMerge extension actually used on Wikimedia sites?
>
> As far as I can see, it is only installed on Wikivoyage, and the last log
> entries of its usage are from 2015. However, it's possible that I'm missing
> something.
>
> The reason I'm asking is that I'd love to know how to configure it best in
> translatewiki. If it's not actually used on Wikimedia sites or developed
> significantly, then it should be filed under "Legacy".
>
> Thanks! :)
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] UserMerge extension on Wikimedia sites

[Thiemo Kreuz]

> Is the UserMerge extension actually used on Wikimedia sites?

I don't know if people *use* it, but according to
https://wikiapiary.com/wiki/Extension:UserMerge it is installed on
more than a thousand wikis, including all Wikimedia wikis.

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

[Thiemo Kreuz]

> […] im adding that functionality to reviewers-by-blame.

I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea to turn this feature set on again? My
impression was more that all the ideas that have been shared in this
email thread describe an *entirely* different approach, following
entirely different ideas, with an entirely different UI, and entirely
different setup. What's the point of stuffing this into the same,
fundamentally broken codebase?

Sysops, please, for our sanity, do not let anybody enable this toxic
plugin again.

Best
Thiemo

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