Yes, it works. Thank you!

IIRC the Webmaster Central URL at https://www.google.com/webmasters/verification/details?hl=en&domain=wikidata.org ought to make it possible delegate owner on that parent domain without conferring other access given that site verification seems to be in place via a TXT record already. No need for the NOC password.

Thank you for the access. I see the "owner" access for those domains but am unable to add users. Would you please grant me access on the wikidata.org parent domain? I think that's what will be needed in order for the DNS verification of the domain to confer the actual permission to add users on the subdomains.

@brion thoughts and pointers on VLC libs?

It'll be a bit before TMH has the updates for things to Just Work™ on the mobile web. And that's still not the app. We're hoping some day a universal file format acceptable on Commons will be supported natively on iOS, but it may be a while yet and it's possible it will require higher end hardware.

Bumping this task. We would like to have a performance readiness review performed in Q4 FY 2020-2021. Exact projected requested start date to be determined and agreed upon within the Abstract Wikipedia team.

Not Phabricator tasks, but something Denny recently shared:

Here's what we discussed early this morning for a web based dashboard, in terms of the inputs and defaults. This is a rough outline, and so it's expected things may diverge somewhat for practical reasons or because of insights gained in further use and development of the web based dashboard.

@Quiddity (Nick) see the attachment on this task for data analysis so far. I'm out the next couple business days, but for our next weekly meeting my goal is to have a good "paper prototype" of a simple web dashboard for being able to drill down to modules based on some heuristics / filters.

@LostEnchanter I think I understand. I believe what you may be witnessing here is that no page uses Module:yesno (lowercase 'y') indirectly (e.g., a page using a template #invokeing some module which in turn requires yesno) on hiwiktionary, and therefore no MediaWiki parser hooks (and manually executed or scheduled link refresh jobs) run in a context where a determination is made to insert an entry into templatelinks.

@tanny411 I think your intuition is probably correct: better to skip iwlinks for now if it's causing too many problems. You can always come back later and see if there's anything of high value there. The other tables queried definitely contain some interesting stuff, we know that much!

Approved

Thinking out loud:

I was able to reproduce the new behavior observed by @Ckoerner on a number of articles on enwiki. Additionally, it seems if one shrinks the Safari window as narrowly as possible the UA is changed so one gets mdot. I was the one who originally reported the bug to Joe. Closing.

Approved.

Thanks @tstarling and @Joe. It sounds like this isn't the right fit for Wikifunctions. I appreciate the advice!

@tstarling, I was wondering if you could please weigh in on my questions above?

Not sure if it's my call, but dropping this to "Low", because although it's true that docker-compose up without the -d flag will keep repeating the error message over and over, if launching in the background with the -d flag (like DEVELOPERS.MD suggests using), I can then run docker-compose exec mediawiki composer update and docker-compose exec mediawiki /bin/bash /docker/install.sh, which will generate the LocalSettings.php.

Hi @tanny411, the Microtask is the same for all. You'll want to start with the Microtask first, and we'll select the intern based on the Microtask entries.

In T263678#6532649, @Udoka_Ugo wrote:

Okay thanks
Here is the link to my microtask, https://github.com/UdokaVrede/Wikimedia-Microtask
Please let me know of any modifications I would be required to make in this report.
Thank you

Hi @Udoka_Ugo. Feel free to post your solution to the microtask to GitHub. Thanks!

Is there anything in the edit URL parameters or in the form POST body for legitimate forms-based and VE editing (i.e., non-bot...I guess unless headless browsing bots do things that evade detection) that could be relied upon?

First of all, cool stuff!

Hi all.

Approved.

@Tnegrin would you please approve?

I believe what's appropriate here is the set of distinct permissions formed from the union of permissions granted to @Mholloway and @MSantos and @bearND, Michael does that sound right?

Thanks @bearND! If I'm reading the patch correctly, @mahmoud you may be able to access Parsoid HTML via the /page/html/{title} or ​/page​/html​/{title}​/{revision} route described at https://en.wikipedia.org/api/rest_v1/ and apply this sort of approach to replicate what used to be available in the experimental API (there may be some utility methods requiring some code spelunking, beware). Hope this helps some.

@bearND would you please point us to the old code that processed references for the experimental API, the one that was decom'd? We looked around a bit and it seems like porting that into clients would probably be the most expedient way for clients to process stuff until there's a new stable References API (iOS is looking at this first).

Thanks for posting those @Krinkle. As part of our Code Health objective in Product Engineering in this forthcoming fiscal year, I'm asking that analysis is lined up on best guess higher criticality tasks of this nature for potential treatment. We'll need to work with you and @Jrbranaa to consider this aspect of code health (technical debt identification, prioritization, and remediation) in this sphere of legacy multimedia components with respect to trade offs for allocation of effort and sequencing of practices, processes, and tools in the bigger picture of the fiscal year for code health.

@mahmoud I believe such an API was being explored in T247858: References API. @eprodromou , heads up in case this is on the nearish term roadmap.

The justification for the access is for reviewing data related to Product Infrastructure and Web features.

As I recall (@leila please chime in if you have contrary info), in order to to correlate a Google Form survey response with the reading and survey CTA impression funnel, it was necessary to have a token in the event logging table and in the Google Form. Showing a form and having a user fill out the form but having no tie back to the reading funnel would chop off one half of the funnel, so such responses would need to be disincluded from the result set. The point here was not to bother such a user with filling out a form if the data wouldn't be used for research purposes because of a severed funnel (stated differently, we also didn't want polluted data sets inasmuch as that's to be avoided). Does that help?

I forget, but yeah, let's unassign me from this epic.

@mahmoud, the decommission of some of the endpoints that are referenced from within api_urls has taken place already, yes. Those endpoints were deemed experimental and thus subject to change without notice. However, I'm sorry to learn that breakage was the way you spotted this.

I adjusted the verbiage to be a bit more general and allow some flexibility in how to handle the rare cases where deprecation gets held up.

Raw data, please.

Yes - thanks for checking.

Approved.

LGTM, but interested to hear thoughts of others.

@Tacsipacsi, that's correct, it would be rendered only on the clients with sufficient JavaScript support. It's not ideal, but it's a compromise to avoid graphs being disabled altogether. Archiving of the PNGs to the File: namespace is one possible way to cut over content meantime where that's preferred over the client rendered approach.

Following up on the meeting, we believe as is the APIs that the KaiOS app is presently using are sufficiently stable. There are some takeaways from the meeting, see the column "2020-05-13 meeting notes" at https://docs.google.com/spreadsheets/d/1IKExDeGhA79pJ1ZzvifWKgwx77-bdRRBJvhvAMAbKeA/edit?usp=sharing for more information.

Deleted things, stopped notebooks and terminals, stopped my Jupyter server. So long notebook1003, it was nice knowing you.

Once the upstream Parsoid fix is in place we'll want to replicate in mobile-actions. @ssastry would you please ping us when the Parsoid fix is done?

Approved

@JMinor would you please confirm if for v1 it's only the checkboxes under "Notify me about these events" that ought to be configurable by apps clients?

Thanks @Nemo_bis for noting. This task is a bit stale. I don't recall the context.

@SBisson thank you for the ping. I'll set a meeting to discuss further.

Way to go, everyone!

Approved

Discussion has been ongoing. Another meeting is set up to cover in greater detail.

@dr0ptp4kt TODO: add acceptance criteria.

Thank you!

Thanks @Jdforrester-WMF.

Noting receipt.

@Mholloway would you please add Gerrit URLs?

@MattCleinman to clarify, is this a regression or pre-existing behavior?

To clarify, is this required ahead of placing on the beta cluster?