@dbarratt: Note that you don't have to add all the text into the preference label itself. There is a help parameter for more detailed instructions: https://www.mediawiki.org/wiki/HTMLForm/tutorial2#Adding_Help-text.

@TBolliger: Figuring out what is deployed where and when is both an art and a science. The best place to start is https://wikitech.wikimedia.org/wiki/Deployments. If we look at https://wikitech.wikimedia.org/wiki/Deployments#Wednesday.2C.C2.A0August.C2.A023, we see that group1 wikis (which includes Meta) are supposed to be updated to 1.30.0-wmf.15 by 2pm today. Things don't always go according to schedule though. In the window for the train deployment you'll see a link to "Blockers: Task T170633". That will let you see if there are any outstanding blockers preventing the train deployment. If there are, you might want to inquire in #wikimedia-operations about the status of the blockers.

Ran foreachwiki sql.php /srv/mediawiki/php/maintenance/archives/patch-ip_changes.sql. Could someone verify that the new ip_changes table is live in all the databases? (Not sure if there's a handy tool for that.)

Niharika will need access to Security tickets, not WMF-NDA AFAIK.

@dpatrick: FYI, we have a deadline on this of September 7, but it's probably the smallest MediaWiki extension ever created, so it should be easy to review. Let me know if September 7th is not going to be doable, so that we can change the schedule for ACTRIAL.

The table should not be in dumps - it could contain revision deleted IPs.

@Bawolff: How are revision deleted IPs currently dealt with in dumps?

@Huji: Typically the way to deal with case 3 is ccnorm( added_lines ) rlike ccnorm( "لغو" ). If ccnorm is used on both arguments, it doesn't matter which direction the mapping is in. And when checks are made against new usernames, it compares the normalized version of the new username with the normalized version of the existing usernames (so the Kurdish/Persian issue shouldn't be a problem as long the characters exist in the mapping). I agree we need to add more non-English characters to the mapping, but I don't see a use case that actually requires separate language specific mappings yet. I originally supported the idea of having separate mappings, but currently I think having a single comprehensive mapping is still the best solution. If there are other use cases I'm missing, let me know.

if possible try to avoid assigning it directly to Jaime

I assigned it to Jaime because the documentation said the task should be "owned by DBA", which should probably be changed to "tagged for the DBA" (or something less confusing).

FWIW, there's a list of all the wiki databases at https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/dblists/all.dblist.

@Pastakhov: Is there any reason we need this config variable?

@DannyH: We need a product decision on this. Do we want one checkbox for the entire matrix, one checkbox per row, or one checkbox per option?

Another option: Start mass importing useful mappings from http://www.unicode.org/Public/security/latest/confusables.txt to equivset.in. By "useful" I mean stuff like:

1D47A ;	0053 ;	MA	# ( 𝑺 → S ) MATHEMATICAL BOLD ITALIC CAPITAL S → LATIN CAPITAL LETTER S	#

but not:

1F319 ;	263D ;	MA	#* ( 🌙 → ☽ ) CRESCENT MOON → FIRST QUARTER MOON	#

@Huji: The more I try to figure out how to actually implement this, the more I think it won't be practical. The main problem is that in real life wikis don't stick to one particular language + character set. Take a look at the Recent Changes feed on Japanese Wikipedia, for example: https://ja.wikipedia.org/wiki/%E7%89%B9%E5%88%A5:%E6%9C%80%E8%BF%91%E3%81%AE%E6%9B%B4%E6%96%B0. The majority of the user names are in Roman/English characters. On Hebrew Wikipedia and Arabic Wikipedia, it seems to be about half. If we only did normalizations in the wiki language, it wouldn't help for half of the users. In most cases, what needs to be done is that both parts of the comparison need to be normalized. That should allow normalization to work in pretty much any circumstance. What is the actual use case that you are trying to fix here?

Here's what I think we should do: Let's implement our own wrapper function around Spoofchecker::areConfusable(), maybe called areSimilar() or something, but augment it with our own (new) list of confusable characters that aren't in the CLDR list (See T65217#3402681 for example). Also, make we are setting Spoofchecker::setChecks( Spoofchecker::ANY_CASE ), so that it is case insensitive.

What measurements are we interested in?

Whatever you need for ACTRIAL, plus some basic ones:

• Page creations per day
• Main namespace page creations per day
• Article (non-redirect main namespace) creations per day

Approved as manager.

@daniel: I hearby request an IRC meeting. Hope that's the correct process for requesting it :)

@dbarratt: Yes, we need to submit the configuration patch, schedule the deployment at https://wikitech.wikimedia.org/wiki/Deployments, and test immediately after the deployment. @Niharika can cover in more detail.

Here's a sketch that Nirzar made with his more recent ideas:

Actually, I lied to Nirzar. Users would not come directly to the landing page from redlinks. They would have to go to the redlink page and then click on the "Create" tab or the "Start the XXXX article" link. Sorry about the confusion.

After talking with @MaxSem, we've decided to append the requested page title as a query string parameter rather than as a subpage so that we get pageview data for free via the pageview API.

Hmm, this might be a lot harder than I thought. The pageview stats are going to be different for every page title, so there's no easy way to roll it up without doing some expensive queries on the raw pageview data. Also, it doesn't look like there's any way to execute JavaScript from the clickable button template. We would have to add some JS to common.js which would bloat page load for everyone. I'm wondering if we should re-think making the entire page live on-wiki, as this makes analytics difficult.

David is a developer on the anti-harassment tools team and thus will commonly need access to data that isn't replicated (as many of the tools he will be working on will be related to private data, such as checkuser, abuse filter, etc.). As David's manager, I approve the request.

FWIW, I have no idea what "checkuser database" refers to. I think they mean the cu_changes table that exists in each wiki database. Any time an email action is performed, it should record an entry in that table with the cuc_actiontext field set to "sent an email to user XXXX" (on English Wikipedia at least). You can see some example data, by running:

select * from cu_changes where cuc_actiontext LIKE 'sent an email to user%' LIMIT 5;

from the enwiki database via terbium.

@dbarratt: It's unlikely you could get a snapshot as the data is sensitive. You can query it directly from terbium (https://wikitech.wikimedia.org/wiki/Terbium).

We might get the pageview data for free. I know that http://tools.wmflabs.org/pageviews/ supports page views for special pages, but I'm not sure how it deals with subpages (like Special:CreatePage/Puppies). Maybe @MusikAnimal would know. Do subpage page views roll-up into the parent page stats? I bet they don't. Is there any way to view the page views for a page and all it's subpages?

@Ottomata: Awesome! Thank you!

The first thing is solved only for Firefox...

Actually, it's solved for every browser except Chrome.

Regardless, should this be a Special Page I assume? Where should I put it (new extension or core)?

It should either be a Special Page or a set of preferences. For me that decision hinges on whether we want to always make these settings global or not. If they are always global, that is a significant departure from how preferences normally work and I think we should put them on a separate special page. If they are not intended to always be global, I would favor including them in the regular preferences, personally. So I guess we'll have to see what comes out of the community consultation. As far as extension vs. core, I imagine this would at least partially be built in core either way. The specific notification muting feature would probably live in Echo, but work through a core hook (either in preferences or a new core special page).

@dbarratt: Hmm, I see what you mean. In the blocking interface, the UI verbiage for disabling email is: "Prevent user from sending email". Maybe we could use similar verbiage:

Mute notifications from these users:
[                                  ]

Yes it is out of scope, but since we know that we're planning on blocking actions outside of Echo (i.e. Special:EmailUser) soon, then I think it's important to figure out if we want to have a single list that covers multiple use cases or just let each extension have it's own list (which I think is a lot for a user to manage).

@dbarratt, @TBolliger: Please do not involve blocking in this feature (as proposed at T171624#3534281). Blocking is a huge can of worms and if we try to incorporate blocking (especially non-admin blocking), I'm afraid it will derail the entire muting project. Can we take blocking off the table here and just concentrate on muting?

@dmaza: You'll want to ask the Performance team, probably @aaron. See also https://wikitech.wikimedia.org/wiki/Statsd.

Special:Block allows you to block a user from sending email (as part of an editing block). This is commonly used against sock-puppet accounts that are created just for harassing people. This workflow has existed for years and works well. I would prefer that we not disrupt that particular feature unless there's a really good reason to.

Also reported for Special:Notifications.

I'm confused. MediaWiki already supports blocking users from using the email feature. That shouldn't be related to the muting feature.

Filled an upstream request at https://github.com/codemirror/CodeMirror/issues/4921 to make the cursor control in CodeMirror configurable.

On what wiki, @kaldari?

My local wiki.

"Wait for Global Preferences to be implemented" seems like the best solution.

Haven't been able to reproduce locally.

@Niharika: I don't understand what you're suggesting. Right now the NWE is the size of the entire article. If CodeMirror covers the entire NWE, it will highlight all of the WikiText (and be slow). If CodeMirror doesn't cover the entire NWE (for example only covering the initial viewport), it will scroll out of view when the user scrolls the page. In order for that to work, in seems like we would have to do some really complicated hackery to make the CodeMirror div slide down the page as the user scrolls the page.

If you consider PROD/BLPPROD + AfD/XfD + speedy deletion "straightforward" :)

@Niharika: But then what happens when the user scrolls? If the CodeMirror div only covers the part of the NWE that is in the viewport, it won't work very well when the user scrolls down.

Yeah, I'm a little unclear on that myself. Reedy reviewed the PHP code back in April. There's some JS code in the extension that should be reviewed as well, though:

@MusikAnimal: I'm confused. What was actually done here? The description lists 2 tasks:

• Remove the xtools dir from the Intuition repo.
• Configure translatewiki.net to start doing translations for the xtools-rebirth repo.

@EdErhart-WMF: See the checklist at T108557.

The problem with PageTriage and FlaggedRevs is that they need to be rewritten from scratch...

Why? The only real issue with making PageTriage wiki-agnostic is figuring out how to support totally different deletion workflows on different wikis. The rest of it is already wiki-agnostic.