Drop proton-staging as it is not used (chromium-pdf.reading-web-staging.eqiad.wmflabs) - can be done after the handoff
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 12 2019
@Capt_Swing: Thanks for the additional detail. Given that, I think it's reasonable to keep both tasks separate.
Feb 11 2019
In T63737#4944679, @Jdlrobson wrote:@alexhollender the click to cancel functionality is now live on beta cluster and ready for this weeks train.
To minimize the traffic sent to the stats endpoint we should track MinervaClientError counter only once after the request is done, not on every error occurrence.
@Joe: Yes. That's correct. Do note that this is the current behaviour for the beta mode of the mobile site (visit https://m.mediawiki.org/wiki/Special:MobileOptions and enable "MediaWiki ß"). I think it's worth wondering how caching best works for both that and this new opt-in feature.
Feb 9 2019
Thanks for hashing this out, y'all. FWIW I think the proposed interim solution seems reasonable.
Feb 8 2019
@Joe: Here's the task I promised to create during the Readers Web/Readers Infra/Services/SRE interlock meeting on Wednesday, 23rd January /cc @ggellerman
Feb 7 2019
FeaturesManager::isFeatureAvailableInContext will need to be updated to take a User object and check the stored value of AMC. This is needed for the talk tab task (T212216).
☝️ I pulled out the very technical AC from the AC section and into the Developer notes section as:
I apologise for not including an approver on the task. I wasn't actually sure who should approve access in this case but realise now that @Nuria would've been the sensible choice.
Feb 6 2019
Thanks!
In T198218#4322957, @Tbayer wrote:Here is the same limited to desktop, but for five months (January-May) instead of one. It confirms that the high number for RecentChangesLinked above wasn't an outlier - it got 13x as much traffic as RecentChanges, which I would have expected to be much more relevant and useful.
_c0 views
https://en.wikipedia.org/wiki/wiki.phtml 61495
What's the rationale for this skipping Needs QA (the first time it moved to Ready for Signoff, I guess)?
In T214444#4905420, @phuedx wrote:This should only involve changing https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/db66eac96fb29beffd89cc40edda1aae99eaee0e/modules/all/ext.wikimediaEvents.readingDepth.js#L21 from dependencies = [ 'schema.' + SCHEMA_NAME ], to dependencies = [],.
AFAICT there's no instrumentation about how (or how frequently) our various overlays are being interacted with. Nevertheless, it's a production feature, so we should do our best to make sure that we don't introduce regressions while doing this refactoring. With that in mind, could we add tests so that this can go through Needs QA.
Feb 5 2019
I'll add a note as to why my proposed change should work and testing instructions for reviewing engineers and @Edtadros.
In T214724#4928097, @Niedzielski wrote:There is also a main page stylesheet.
Is there any chance that you did get time to look at this during All Hands, @hashar? I know it was very busy.
Jan 30 2019
select round(sum(if(uri_query like '%Special:Log%', 1, 0)) / sum(1) * 100, 2) as log, round(sum(if(uri_query like '%Special:AbuseLog%', 1, 0)) / sum(1) * 100, 2) as abuse_log, sum(1) as all_clickthroughs from wmf.webrequest where year = 2019 and month = 1 and day = 28
Jan 29 2019
- other action=history views e.g. https://en.wikipedia.org/w/index.php?title=Antlia&offset=20170119050717&action=history )
- by number of items (20 | 50 | 100 | 250 | 500)
Jan 25 2019
I've added T203042: Output 2.2: Characterizing readership by demographics as a parent task as this task was split out of T213696: Sample by title in QuickSurvey (see T213696#4881990) and has it as its parent.
Should this be moved to *Needs Design Review* per ☝️?
This looks like a duplicate of T139317: Allow quicksurvey to target based on edit count (or vice versa). Anyone mind if I merge 'em?
Jan 24 2019
This should only involve changing https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/db66eac96fb29beffd89cc40edda1aae99eaee0e/modules/all/ext.wikimediaEvents.readingDepth.js#L21 from dependencies = [ 'schema.' + SCHEMA_NAME ], to dependencies = [],.
Jan 22 2019
☝️ Per today's standup ritual.
Jan 21 2019
☝️ /cc @Edtadros
For posterity, the draft report is published here: https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues/AB_tests
Jan 18 2019
We appear to be capturing the appropriate information in the PrefUpdate schema (see below) though it's a shame we don't capture the source of the update as well.
@ovasileva has sent the request. We're waiting for a response.
Jan 17 2019
Hrrm… I thought we might be able to listen to [[ https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#event-response | the response event ]]. I'd assumed that the headers property was mutable but you might be right.
This seems High priority to me, @ovasileva. It also seems like a regression, right?
Ping @hashar, @zeljkofilipin: Has any progress been made on this? Like the Wikidata folk, Readers Web can't move forward with T190710: Minerva Ruby and Node.js browser tests running side by side because of this issue.
Yesterday afternoon, I opted in and out of mobile beta mode whilst logged in with my Phuedx (WMF) account (ID: 22867088, see [1]).
Since rEMFR7999d121a130: Introduce `advanced mobile edit` change tag introduces both the tag and the tagging of edits made by users opted into AMC, we should update the QA steps so that the latter is exercised.
In T213362#4886925, @Pchelolo wrote:We definitely do not want the CSP to vary by user agent, so we need to look how narrow we can make the CSP without breaking anything. I think wikidomain + *.wikimedia.org + wikidata (just in case) should work well. I'll look into it.
Olga's currently drafting the request.
Jan 16 2019
Can I ask that an outcome of this epic be well-written documentation about how to author new overlays both within and without the MobileFrontend/MinervaNeue codebases?
This is currently blocked on a privacy review.
Jan 15 2019
Jan 11 2019
Very neat, @Krinkle! That approach'll require a fair bit of explanation in the QuickSurveys documentation for future developers (covered by AC 3)
Jan 10 2019
I removed the duplicate information from the description but should clarify the following:
The client-side error rate has since fallen to its previous level: https://grafana.wikimedia.org/d/000000566/reading-web-dashboard?orgId=1&panelId=15&fullscreen&from=1547035200000&to=now&refresh=5m
In T209882#4869179, @bmansurov wrote:@Jdlrobson thanks for spotting this. I wonder what a proper fix would be. There's got to be a way of removing that config. Hopefully the fix reduces the errors.
☝️ Formalizing T212959#4867678.
Jan 8 2019
Here's the GettingStarted extension's implementation of edit tags: https://github.com/wikimedia/mediawiki-extensions-GettingStarted/blob/ae9542e45f722c5f700ed4434dca47d561394794/Hooks.php#L328-L363
Thanks for the ping, @charlotteportero. This can safely be declined for now as the Marvin project is being archived.
Do note that this task focusses on making the change in our application code, which is made possible by restricting AMC to logged-in users (who are always served by the application servers). It may be prudent to home all of our X-Analytics-related logic in the Varnish VCL's themselves.