It is now present in InitialiseSettings.php. I'm not sure where we would document something like "if you're an SRE person and are thinking of disabling ORES, please try disabling the ORES UI first". I'm also not sure how receptive they'd be to it, because one could argue that a "disable the extension first and ask questions later" situation doesn't call for that kind of nuance.

I think this is a good direction, but I'm skeptical that we can, without a lot more effort, get rid of browser QUnit tests. A number of them depend on the MediaWiki environment (or literally on being in a browser) and it can be difficult or cumbersome to mock the MW environment and/or the browser environment (including the DOM) faithfully enough to make these tests work.

Whoops, I guess I shouldn't close this yet, because goodfaith isn't done yet. In any case, damaging is now live.

The jsfiddle broke, because it made lots of requests in parallel and triggered 429s. Here's the new one that does work: https://jsfiddle.net/catrope/7hfg3drv/

In T215354#4950607, @Ladsgroup wrote:

In T215354#4950181, @Catrope wrote:

Forgot to say this earlier: I've scheduled the above patch for deployment on Thursday February 14 at 00:00-01:00 UTC (Wednesday 16:00-17:00).

Please don't do it for German Wikipedia. The wiki banned using ORES a while back (three or four years ago, a little bit after the Mediaviewer stuff). Deploying it without community approval first probably will cause a mayhem.

Forgot to say this earlier: I've scheduled the above patch for deployment on Thursday February 14 at 00:00-01:00 UTC (Wednesday 16:00-17:00).

In T211032#4949099, @Halfak wrote:

@Catrope, we can probably get this out in the next deployment -- which could be tomorrow or Thursday. I hope that won't be too disruptive. Thanks for your report and your patience!

• As part of converting from a user script to a gadget, you can (and should):
  • Remove the mw.loader.load() call that loads the CSS. It already gets loaded because it's in the gadget definition
  • Instead of wrapping everything in mw.loader.using( 'ext.eventLogging' ), define this dependency in the gadget definition, like so: userfeedback[ResourceLoader|dependencies=ext.eventLogging]|userfeedback.js|userfeedback.css
• Confusingly, wgTitle is not a very useful variable, and mw.Title.newFromText( title, namespaceNum ) is not the best way to make a Title object for the current page. Instead, I recommend mw.Title.newFromText( mw.config.get( 'wgPageName' ) ) (and if you do this, you can get rid of the namespaceNum variable too)
• When building HTML using string concatenation, you have to escape attributes that could contain special characters. There's only one instance of that in this code: "<a href='" + talkPageUrl + "' target='_blank'>blah</a>" should be "<a href="' + mw.html.escape( talkPageUrl ) + "' target='_blank'>blah</a>
  • Ideally, you wouldn't build HTML with string concatenation at all. jQuery lets you build DOM nodes programmatically (but that's a little bit more verbose, see below)
• IDs should be prefixed to avoid naming collisions. thumbs-up is too generic of an ID, I suggest something like mw-userfeedback-thumbs-up (and something similar for the others). The class name thumbs is also pretty generic, but that's not as much of a problem because all your CSS rules for it are limited to within the #doc-feedback-form div; ideally, though, this would be prefixed too.
• Our coding conventions say to:
  • • use === instead of == (but !== is correct)
  • use 'single quotes' for strings where possible (this code uses a mix of 'single quoted' and "double quoted" strings)

Not sure why I wrote a FIXME comment here, we do in fact need to do that to avoid breaking things.

I've scheduled the above patch for deployment on Thursday February 14 at 00:00-01:00 UTC (Wednesday 16:00-17:00).

In T201574#4941131, @gerritbot wrote:

Change 460954 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Export config vars in the RL modules where possible

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

Echo sends daily or weekly digests of notifications when requested (it's a user preference), using a cron job that runs every day at 00:00 UTC.

except that within ContentBranchNodes, the offset is the linearized offset of the position.

I assume this means that, given linmod [ {type: 'paragraph' }, 'a', 'b', 'c', { type: 'image' }, { type: '/image' }, 'x', 'y', 'z', { type: '/paragraph' } ], the path of the offset inside the image is [0, 4], whereas it would normally be [0, 1, 0]? I think this is a good idea, and one reason for that is that otherwise it's ambiguous whether the path of the offset after 'c' is [0, 0, 3] or [0, 1].

Overall, I'm concerned that the scope for the task recommendations module might become too big for Q3.

I have the same concern. If we scope it down a lot, and take some shortcuts like the category thing Morten suggested, we might be able to do something more quickly. But I think it would be better to focus on simpler modules first. I'll dive deeper into some of the possible backends that were floated for task recommendations, and write a separate comment about that later.

In T209114#4905939, @kostajh wrote:

Should we store a subset of the full HTML document that contains only the essential pieces of information?

Yes, good idea. Maybe we can store only the <body> tag. Right now we store the contents of the body tag, but if we instead store the entire body tag (including attributes), we get most of the important information, and we can encode any other information we need as data attributes on the body tag.

In T111624#4650007, @Dalba wrote:

(BTW, I think the issue is actually related to mw.config.get( 'wgPageName' ) returning null on that page, which I'm still unable to find out why.)

There is no list of namespaces where mentions are expected or not expected. Instead, the code looks at the diff to see whether a signature was added. That's not exactly a great way to do it, and it causes issues (mentions being eaten in cases where the signature isn't detected, or was forgotten and added later), but that's how it works right now. My favorite proposal to fix this broken system is T128535: Consider ping parser function instead of link-based mention.

@Niharika Is the Community-Tech team still working on log entry thanks, or is this our responsibility now?

I'm seeing related-looking thumbor errors in logstash for this file and others, but all it tells me is that the gs command failed, it doesn't tell me why.

Hmm now it's 500ing instead...

What's especially strange about this is that https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Global_Wikipedia_and_Wikimedia_Brand_Research_Report.pdf/page1-800px-Global_Wikipedia_and_Wikimedia_Brand_Research_Report.pdf.jpg persistently returns a 429. Refreshing it just returns a 429 from a different Varnish server. If you replace page1 with page2, you do get a response, but if you change 800px to some other file size (for page1), you still get a 429.

The defaults are as follows, but I eyeball the results and adjust where needed. For example, if the 90% precision level has a low recall (lower than 8% or so), I'll choose the 80% or 75% precision level instead. One formalism I do use: "maybe bad" is 15% precision or 90% recall, whichever of those two produces a narrower threshold range.

We discussed this in our triage meeting this week, and decided to decline this task because filled/unfilled bullets are not being used to communicate anything meaningful on RecentChanges (unlike Watchlist, where filledness does mean something).

We discussed this with the team earlier this week.

We're planning to address this in the coming few months, possibly later this month.

In our triage meeting this week, we decided to decline this, because the help panel is aimed at new users, who generally don't know how to switch to a non-default skin like Monobook.

In T212967#4871062, @matmarex wrote:

Alternatively, you might want to integrate your code with VE so that it knows about your dialog and manages opening/closing it. Roughly like this:

function BlahBlahDialog () {
	BlahBlahDialog.parent.call( this, arguments );
}
OO.inheritClass( BlahBlahDialog, OO.ui.ProcessDialog );
BlahBlahDialog.static.name = 'blahBlahDialog';

mw.loader.using( 'ext.visualEditor.desktopArticleTarget.init', function () {
	mw.libs.ve.addPlugin( function ( target ) {
		ve.ui.windowFactory.register( BlahBlahDialog );
	} );
} );

// Some time later, to open the dialog:
ve.init.target.getSurface().execute( 'window', 'open', 'blahBlahDialog' );

Related to T55479: Notification emails should embed icons as data URIs

This sounds a lot like T207941: Spike of DBTransactionSizeError exceptions from /w/api.php from Special:Watchlist

In T175773#4662310, @SBisson wrote:

enwiki has the "revert", "undo" and "rollback" tags. See https://en.wikipedia.org/wiki/Special:RecentChanges?tagfilter=revert%7Cmw-rollback%7Cmw-undo&limit=500&days=30&urlversion=2

I don't know who/what is putting those tags but it seem to work well.

No, I don't think it's directly related to the timeout issue, but from your console screenshot I do think that a JS error (caused by an assumption that EventLogging is available while it's not) prevented the error from being rendered. Confusingly, I can't find mw.eventLog or .schemas anywhere in the Flow code base, neither now nor at the time that you filed the bug, so I don't know where the error (or the assumption that EventLogging is installed) comes from.

This happens because the ThanksLogTypeWhitelist config only lists top-level log types, not type+action combinations (subtypes, basically). In this case, it lists the type rights, but we really only want to allow thanks for rights/rights, not for rights/autopromote. A code change would be needed to accept subtypes in this list.

Does the help panel part of this bug still happen, now that we've prevented iOS from zooming in on the question input when it's focused?