This is subsumed by the Worldwide Readership MTP deliverables.

And the wikis rejoiced! Thanks everybody!

This revision definitely looks cleaner! Are we ready to try with N'Ko in production?

thanks for the update!

Awesome -- do you feel confident enough to try with N'ko from T230359?

I think getting this script working without manual intervention would be a good first step. @aaron -- I think this is back to you...

Thanks @Ladsgroup ! Our emerging language communities will be thrilled :)

So it looks like this is potentially fixed? @kchapman -- not sure about the workflow here...does your team want to check to see if Aaron's patch works? Thanks!

This ticket was identified as high priority at Wikimania - @kchapman is this something your team could take on?

We might want to mention this at Wikimania (7/16)

Approved

Adding the SDC folks as we probably want to think about how this integrates with structured data. Or not.

Hi Runa, Angie -- some interesting work on the relationship between content and readership from Chelsy. I think this supports content creation for NR readership.

I have no phab token skills, but this is awesome Chelsy! Thanks for the follow up.

I should also say this is not urgent, I've got this in a todo list and need to move to phab!

approved

I just want to be clear that we need to understand the relationship between the load times and how much people use the site. (PVs/UDs) -- it helps us understand how people use the site and the boundaries of how much speed contributes to usage.

what if this fix was in the eventLogging code itself?

We gotta figure this out - this error needs to fail sooner than hive!

This really should be addressed in the schema validation for event logging.
Is this possible?

Can we please rerun the usage numbers across all of the wikis using Matmarex's technique above. I don't really feel like we have consistent usage numbers.

Folks -- this is for a high priority, community visible project (ACTRIAL) -- we really need this data. How can I help move this forward?

approved

Thanks Neil!

A quick review of Dan's data shows that articles created by autoconfirmed users are definitely deleted at about a 30-40% rate.

Thank you everyone for the hard work!

Thanks Neil -- there is some urgency. Please do an initial estimate of time
and we can get some help if need be if this will go past Friday.

Just to capture Kaldari, Danny and my discussion on this -- we actually need to know how many deleted articles were created by autoconfirmed users.

The best time to plant a tree is 20 years ago. The second best time is now.
:)

omg -- it works and it's wonderful. Thanks all!

We had the meeting and have a good understanding of the issue. There are some technical issues regarding keeping the UX the same as the GET version so we're going to have to assess the tradeoffs around different implementations. We'll keep the ticket updated.

yes -- today!

[Comments by @TheDJ on the original thread]

I will set up a meeting with designers and move this forward.

Bumping this -- any ideas of when/if this needs to happen?

Please work with discovery on methods - assessing lists of ranked results
is what they do.

Don't know how useful this will be but Discovery has a tool that can be used for humans to test search results:

Yes but maybe not to DR. It's relevant to finding a scaling factor for
unique devices to estimate a correspondence to actual people.

Hi Folks -- this task lines up with work reading is doing with Comms on metrics. I'd like these efforts to be aligned as they are critical to the how the Reading team measures and communicates its impact.

It's not the money per se - it's just a budget formality of putting the
money in the right bucket.

@kaldari Are we still considering google? Was there a budget problem with using their service?

I haven't logged into anything except my MacBook in months so I think
you're good to go!

Sorry Chase -- I don't actually need this now since I don't manage the
analytics team anymore. Probably best to remove the access.

I'm honestly not sure what this would accomplish now. The Reading team has abode by community wishes communicated by an RFC and have disabled the feature. All of the people who were responsible for Gather on a decision making level have been gone for more than a year.

Thank you Ori

I would like to delay this patch (not deploy today) until the discussion has a chance to finish up. However, I can't actually do this. Can someone grab this task?

To keep the archives happy:

It turns out that per @Moushira, Village pumps also don't render well on mobile.

Other pages with issues on mobile:

Looks like MassMessage then?

ok -- we have the text of the message. Can someone please tell me how to
send it?

See ask for docs/resources on https://phabricator.wikimedia.org/T123142

Hi all -- Nemo's asking for some documentation on this service. Any chance we can get this scheduled? Happy to help find the appropriate resources.

sweet.

From my perspective, I want T114072 to happen because it helps with
presentation issues but I don't have the context to part of a discussion.
Real time editing seems more suited for the summit.

Hi Quim -- we'll take a look next week. It's very connected to the work on the mobile presentation that we're doing right now.

If people turn it on, then off, will we be able to count them?

Thanks Florian!

Hi Adam -- we should review this "soon" as it potentially impacts users who are trying to increase page performance by not downloading images but have the additional undesirable effect of disabling the cache.

T114542: Next Generation Content Loading and Routing, in Practice (+ T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

I have experienced this bug multiple times over the last few weeks. It
causes the article to be unreadable on my iphone. From my perspective this
is a high priority issue.

I think we can find a balance between a power user's IDE view of editing
with lots of tools versus and relatively simple editing experience for
newbies/anons. I'd like to think of the two experiences as 80/20 rather
than 100% either way.

Hi Moushira -- would love your feedback on this. Thanks!

I think so -- this is primarily is response to some discussions with
community folks who say that they actually will pull pages up in a mobile
to see how they render. It would be nice to have this be part of the tool.

We're pulling this into this sprint; there are a few minor UX issues to explore but we'd like to get this done now.

I agree with the SWAT deployment. Thanks for the quick response all.

Argh -- wrong parent.

Argh -- I'd like to move forward with the suggestions Adam captured in the
previous comment. I'll create a sub-ticket for the IRC channel and for
communicating this out.

I'm disappointed that it took this long, but it is done.

I wonder if we redacted the W0 numbers in 2.0. I seem to remember some
concerns about sharing those publicly.

[continued] so I would support keeping the status quo for now.

Thanks Krenair - qchris has my complete trust and support for any access he
feels is appropriate.

Congrats Dan and team -- nice to see this so close.

Anne's doing this as part of her work for the readership team and I approve.

I agree with bd808 -- we need to decide what data we need to support our
use cases and record just that, subject to normal privacy/ethical concerns
of course. We should take this approach across the board.

I talked to Bob West -- there are some other options we can investigate for
populating the lists.