In T223408#5198738, @Gilles wrote:Ian Marlier participated in the site maps project as his own personal initiative, but it has always been out of scope for the Performance Team. And his knowledge of that project left with him, so we're not better equipped than anyone else to do something about this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
May 21 2019
May 21 2019
Per T209377#5197164 and T209377#5200890.
phuedx closed T209377: Remove A/B test and launch to 100%, a subtask of T209306: [Epic] [SEO] Enable Schema.org Article linked data for all main namespace pages, as Resolved.
- Delete PageSplitTester and PageSplitTesterTest from Wikibase (this will move to Core in T209319)
- Delete PageRandomLookup and PageRandomLookupTest
- Delete related configuration variables from Wikibase
May 14 2019
May 14 2019
phuedx updated the task description for T223206: [Hackday] Analyse user interactions with RecentChanges.
phuedx updated the task description for T223206: [Hackday] Analyse user interactions with RecentChanges.
phuedx updated the task description for T223206: [Hackday] Analyse user interactions with RecentChanges.
How frequently is live updates enabled?
phuedx updated the task description for T223206: [Hackday] Analyse user interactions with RecentChanges.
phuedx updated the task description for T223206: [Hackday] Analyse user interactions with RecentChanges.
@MNeisler: As discussed: I'll take How frequently to users change the limit and days parameters?
May 9 2019
May 9 2019
AIUI this isn't High priority but a nice to have. Is that correct, @bearND?
phuedx added a project to T222681: WikidataPageBanner uses a blacklist of skin names to decide 'prebodyhtml' support instead of sane feature detection: Web-Team-Backlog.
Ping @Jdlrobson (the extension's author IIRC).
May 8 2019
May 8 2019
Setting up a development environment could be as trivial as adding the following to MobileFrontendHooks::onOutputPageParserOutput:
This LGTM.
phuedx closed T217220: Post-inheritance cleanup, a subtask of T212465: [EPIC] None of our View's should exhibit 2 levels of inheritance, as Resolved.
🎉🎉🎉
Apr 29 2019
Apr 29 2019
phuedx closed T220159: Inline templates for mobile editor, a subtask of T94086: [EPIC] Migrate MobileFrontend templates from hogan to inlined mustache templates, as Resolved.
Increase in JS bundlesizes should be consistent with the removal of the size of ResourceLoader's mobile.startup module. Change in bytes shipped to client should be recorded.
phuedx moved T219846: Remove "mediawiki.template.muhogan" from RelatedArticles from Ready for Signoff to Needs More Work on the Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q4) board.
There are a few nitpicks (their words) from Timo Tijhof on @Jdrewniak's change: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/RelatedArticles/+/502529/3/resources/ext.relatedArticles.cards/CardView.js
I feel comfortable signing this off in @ovasileva's absence.
Apr 26 2019
Apr 26 2019
In T220627#5125187, @Nuria wrote:Moving to radar as further steps of code chnages to Quicksurveys to fix loading issues with JS should be done by (i think) @phuedx team?
💪
phuedx updated the task description for T218627: Upgrade MobileWebMainMenuClickTracking to have an AMC field.
Document the oversampling behaviour for AMC on the schema's talk page so Tilman can understand it
phuedx updated the task description for T218627: Upgrade MobileWebMainMenuClickTracking to have an AMC field.
Update the schema revision number in MobileFrontend and move to Minerva codebase
Sampling rate should be 100% if the user is AMC, otherwise use the configurable sampling rate
Log whether the user is in AMC mode using the new schema revision ID
phuedx updated the task description for T218627: Upgrade MobileWebMainMenuClickTracking to have an AMC field.
phuedx updated the task description for T218627: Upgrade MobileWebMainMenuClickTracking to have an AMC field.
Update the schema to have an AMC flag
phuedx closed T208980: [Bug] The statsv client should send a request when the page unloads so we are not losing events as Resolved.
Thanks to @Krinkle both for discussing this issue and for the prompt review and merge.
phuedx added a comment to T208980: [Bug] The statsv client should send a request when the page unloads so we are not losing events.
- Add an annotation to https://grafana.wikimedia.org/d/000000566/overview?panelId=15&fullscreen&orgId=1 at the time when the change is deploying
phuedx updated the task description for T208980: [Bug] The statsv client should send a request when the page unloads so we are not losing events.
AIUI this task has been blocked on a request for privileges on some (all?) of the Wikipedias. The request has stalled, insofar as it hasn't been rejected nor has it been resolved, since giving a test account such privileges on production wikis will be viewed with suspicion by the community and may result in unintended outcomes.
I feel comfortable signing this off in @ovasileva's absence.
phuedx moved T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages from Triaged but Future to Needs Prioritization on the Web-Team-Backlog board.
Per T220751#5137468, above.
phuedx removed a project from T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages: Patch-For-Review.
Apr 25 2019
Apr 25 2019
phuedx edited projects for T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages, added: Web-Team-Backlog; removed Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q4).
phuedx added a comment to T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages.
I'd meant to follow up on this:
Apr 24 2019
Apr 24 2019
phuedx added a comment to T188697: Not possible to configure Minerva main menu to use Special:RandomRoot instead of Special:Random.
In the interest of fixing the discrepancy (at the expense of punting the more general problem, captured in T65459: Allow configuration of the Minerva menu), can we update [[ https://gerrit.wikimedia.org/g/mediawiki/skins/MinervaNeue/+/8086325cd25af356149dbd65f58b780caff4a67b/includes/menu/Definitions.php#191 | MediaWiki\Minerva\Menu\Definitions::insertRandomItem ]] to use
phuedx lowered the priority of T219212: Augment ReadingDepth schema with data from Page Lifecycle API from High to Medium.
I'll follow up with Kate Zimmerman and Megan Neisler about how the ReadingDepth instrumentation fits in with their priorities.
In T214715#5134590, @pmiazga wrote:Editors can update URIs of menu items e.g. On Commons, Special:Random can be replaced with Special:Random/file (see T188697)
- override the Definitions::insertRandomItem() to use the message cache. Instead of hardcoding Special:Random, we can load the title from Mediawiki:Random-url
I'm comfortable signing this off. Although one AC isn't satisfied, there's at least one task covering the community request. I'll follow up on that task with a simple suggestion that could get it unstuck.
phuedx closed T214715: [Spike] How should menus work in Minerva?, a subtask of T214537: [EPIC] AMC Navigation - changes to main menu, as Resolved.
Editors can update URIs of menu items e.g. On Commons, Special:Random can be replaced with Special:Random/file (see T188697)
A menu can be converted to a JSON of template properties so that it can be rendered by JavaScript via Mustache
A menu itself be made of multiple menus e.g. left hamburger navigation has 4 menus right now in stable
A menu uses a [Mustache] template for rendering so that it can also be used on the client.
Menus should work without JS
A menu can have completely different contents in a given mode e.g. contributions might be in left menu on stable but in a new user menu that shows on hover in AMC mode
It should be possible for an extension to register a menu item in a certain menu without any knowledge of how the menu is rendered.
Apr 18 2019
Apr 18 2019
Also! Thanks, everyone!
I've been noodling on proposing that @Stashbot and/or scap create annotations in Grafana. I think such annotations would've been useful here.
Apr 17 2019
Apr 17 2019
There's a spike in VirtualPageview events today (see https://grafana.wikimedia.org/d/000000018/eventlogging-schema?orgId=1&from=1555459200000&to=1555516800000&var-schema=VirtualPageView) which appears to correspond to today's updates to the cluster. Further confirmation?
From the SAL:
Apr 15 2019
Apr 15 2019
In T382#5108028, @Milimetric wrote:Thanks @Tgr, that's a big pivot from what I was expecting, but hey, let's do it!
In T218627#5110077, @Edtadros wrote:In the likely event I'm doing it wrong, after I click on the hamburger menu, I right click on Random and open that in a new window. <snip />
Apr 12 2019
Apr 12 2019
In T220627#5107552, @Isaac wrote:And when do events for QuickSurveyInitiation and QuickSurveysResponses trigger?
- We are supposed to get a QuickSurveyInitiation every time the extension shows someone a survey: https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/c40f824c79b4e98993dafe7416a60fd6ad9cce45/resources/ext.quicksurveys.views/QuickSurvey.js#L100
@ovasileva: This might benefit from some investigation on our side too.
Apr 10 2019
Apr 10 2019
phuedx added a comment to T212800: AMC feature flag can be superseded by a development query parameter.
Do consider that this change might be useful for setting up automated browser tests targetting AMC mode available/unavailable, since the Node.js stack doesn't support a local LocalSettings.php file.
Apr 9 2019
Apr 9 2019
Additional notes that I raised during today's Backlog Grooming meeting:
In T219841#5096041, @Jdlrobson wrote:cc analytics and RelEng as there's potential for a lot of traffic to EventLogging (I've seen 80k a minute) to the WebClientError schema
Apr 8 2019
Apr 8 2019
phuedx lowered the priority of T208980: [Bug] The statsv client should send a request when the page unloads so we are not losing events from Medium to Low.
Apr 5 2019
Apr 5 2019
@Tgr: When can this work be scheduled?
One alternative would be to launch the child Chromium process using firejail, which we're confident (?) does this kind of management.
In T217724#5044953, @pmiazga wrote:@akosiaris - yes, there is some logic that tries to kill the browser instances if browser.close() promise doesn't succeed. Looks like this code requires some tuning, and most probably it should try to kill the browser instance after some time without waiting for promise resolution/failure.
@Tgr: We'd talked about the deployment of this code having stalled out. Does this need a security review or at least an OK from Security prior to being deployed?
Work out how to deal with the frustration of non-deduplication. The feedback we got from people who have used EventLogging is that having the stack traces allowed them to fix the common bugs, but the other ones were harder to track down. We have no idea of the spread of our errors - all of them could be different, or many of them could be duplicates. We should think about what queries we can use to de-duplicate errors (And work out how many people they impact) and how our stack trace can be structured to help facilitate that.
Add stack traces to WebClientError events. Right now we're not including them in the current implementation because of the URL length. These will be essential. See T202026 for more information.
After thinking about this a little, it'd be useful for extensions/skins to be able to register a module that'll act as an error handler. AIUI the Sentry extension will suffer from the same issue as there's no guarantee that it'll be executed before the things that it intends to monitor will.
Apr 4 2019
Apr 4 2019
phuedx awarded T219828: Refine eventlogging pipeline should not refine data for domains that are not wikimedia's a Mountain of Wealth token.
phuedx updated the task description for T219212: Augment ReadingDepth schema with data from Page Lifecycle API.
phuedx updated the task description for T219212: Augment ReadingDepth schema with data from Page Lifecycle API.
phuedx updated the task description for T218304: Allow quicksurveys to target based on registration date.
In T219212#5070027, @Tbayer wrote:Yes, great point! I'm still slightly wondering about compatibility/comparability though - is it correct to interpret the documentation as saying that in cases where the unload event fires correctly, it should coincide with the pagehide event (with terminated state)?
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL