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?

Done. https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/services/push-notifications

Here's the Sheet: https://docs.google.com/spreadsheets/d/1IKExDeGhA79pJ1ZzvifWKgwx77-bdRRBJvhvAMAbKeA/edit?usp=sharing

@bearND @MSantos @jlinehan would you please weigh in?

Heads up, I'm going to create a Sheet for us to work out each endpoint and will loop people in there and link to it from this ticket as well.

@Nuria I added webhost to druid_load.pp for this more narrow treatment - see https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/587984/6..8/modules/profile/manifests/analytics/refinery/job/druid_load.pp at the far right side of the diff.

Patch is ready for review and deploy.

Cool. I'll update the patch to add webhost and 90 days is good.

Noted, will get back to this ticket.

@kaldari should weigh in on the 90 day window.

Yep, that works.

Thanks @Mholloway. Those are good ideas. Would any of the following work as well?