PR: https://github.com/wikimedia/eventmetrics/pull/194

PR https://github.com/wikimedia/eventmetrics/pull/193

Ready for QA! The report is accessible at /programs/:programId/events/:eventId/pages-created, e.g. https://eventmetrics-dev.wmflabs.org/programs/81/events/141/pages-created

Merged. This can be QA'd using the Event Summary report.

Follow-up PR at https://github.com/wikimedia/eventmetrics/pull/191

Okay, PR 189 was merged. Moving this straight to product sign-off, since the only thing different is the extraneous Participants count.

Merged and ready for QA.

Merged and ready for QA. The example event we use in the integration tests includes some redirects, see https://github.com/wikimedia/eventmetrics/blob/master/src/AppBundle/DataFixtures/ORM/extended.yml#L11-L51 for the details. Hopefully that code is decipherable.

In T214744#4962374, @jmatazzoni wrote:

...Wikipedias, categories will continue to restrict metrics only for Main namespace pages. Category filtering has no effect on files uploaded to Wikipedias. Which means that all "Files Uploaded" to local wikis will continue to be counted, no matter what categories they are or are not in.

PR: https://github.com/wikimedia/eventmetrics/pull/187 (same as T205502)

Whoops, I did this as part of T205502. Didn't realize it was a separate task. Very simple addition https://github.com/wikimedia/eventmetrics/pull/187/files#diff-6290201f755154950df266ebb23cdd65R547

Nope. That is just a mistake; the duplicate needs to be removed. Moving this back to In Dev so @MusikAnimal can take care of that detail.

Okay, ready for review now :) PR: https://github.com/wikimedia/eventmetrics/pull/189

Not quite ready...

Same issue as T206692#4963802. Recently we started storing the Participants as a stat, so it automatically shows. There was still some code in there that manually showed it, hence the duplication/misalignment.

In T206817#4965382, @jmatazzoni wrote:

MusikAnimal, excluding redirects is probably a good idea; do you want to write a task for that?

PR: https://github.com/wikimedia/eventmetrics/pull/188

In T216304#4962606, @jmatazzoni wrote:

@Niharika @MusikAnimal, in order to include the new metrics but save vertical space, so as to make the filters discoverable, I put into the design requirements that:

...it's not clear to me that the per-wiki metrics are required. If people want per-wiki metrics, they can get them in the relevant reports.

If there is some reason I don't see why per-wiki metrics are important on this page, now that we have downloadable reports that can give per-wiki results, then please speak up.

If a page gets moved (by a participant) that would count as 1 page created (the old redirect page, assuming they don't delete it) and 1 page improved (the renamed page).

The correct date format for the URL is YYYY-MM-DD, e.g. https://xtools.wmflabs.org/pages/en.wikipedia.org/Lord_Coutts/0/noredirects/all/2014-01-01/2018-12-31, which is what you'll get if you use the form at https://xtools.wmflabs.org/pages. Also there doesn't appear to be an account registered with the name "Dean Swinscoe".

Recent data shows some 50-110 records a day -- usually the higher end of the range -- consistent with historical data. Maybe whatever was broken a year ago has fixed itself, or it was just coincidence. Closing as resolved for now.

Things should be stable now. Indeed we should have better error handling. Saving that for a rainy day.

It's back up and running for now, but until T216208 is resolved more issues may arise.

I don't know why CopyPatrol didn't show up, but it also needs to be updated to support PHP 7.2. PR at https://github.com/wikimedia/CopyPatrol/pull/58. I've got production running on this branch so that it's functional, and also am using the PHP 7.2 Kubernetes container, as recommended by Cloud Services.

Another use-case is https://en.wikipedia.org/wiki/Special:AbuseFilter/944. It targets articles that are linked to on the Main Page, so it needs to be updated manually everyday. It would be to awesome have a bot do it for us!

I assume you'd only be using the source maps in development, right? In that case you can run Encore in dev mode with ./node_modules.,bin/encore dev, and the source will be unminified/unuglified. I think if you set it up right it will generate each file individually instead of concatenating into one, too.

popularpages needs to be bumped to PHP 7.2 to work on Stretch (at least without warnings). PR at https://github.com/wikimedia/popularpages/pull/8