Note that following T210682: Don't refresh fixed data if last updated datestamp is after end date of the event we will need this report to check the archive table if the page doesn't exist in page. All the metrics listed above are actually still available after the page is deleted, only we'd need to refer to a different table.

There is also an edge case where a page is oversighted or revision-deleted, in which case it won't be in page or archive.

Desirable but not for MVP / Deprecated Metrics

This is a list of metrics we'd wanted for this report but which were judged out of scope for the first MVP

• Bytes changed subsequently
• # of words changed subsequently
• Still exists? [T206695]
• Words added during event [T206690]
• Words removed during event [T206690]
• Net % change in words during event [ T206690]
• Article class (where available)

Note that most of the work for this will be done with T205502. Wikitext is easier since we can do our development within the browser, as opposed to having to download CSV and open it in spreadsheet software over and over.

@MusikAnimal, FYI I changed the spec in the Description of "Bytes changed" slightly to get rid of the + for positive numbers—because it makes the number align left instead of right in CSVs (they don't see it as a number anymore). The - for negative numbers is OK though, and doesn't have that problem. Here is the new spec, fyi:

• Bytes changed during event The net bytes changed to the page during the event period. If the "Bytes changed" is a negative number, please include a - (but don't use a + for positive numbers).

FYI I changed the spec in the Description of "Bytes changed" slightly to get rid of the + for positive numbers

Got it, thanks!

This is ready for review: https://github.com/wikimedia/eventmetrics/pull/204

Checked the correct figures for some wikidata items (I have not really tested wikidata up to this point). Saw no problems, although I did not know where to get figures for page views.

@MusikAnimal The only problem I saw was that it did not appear to be correctly encoding apostrophes. For example, https://eventmetrics-dev.wmflabs.org/programs/76/events/259 has cells such as "Switzerland women's national under-20 volleyball team" (effects both Title and URL columns). Perhaps similar to T215923? The encoding is correct in the wikitext format.

I also checked that I could perform mathematical operations on the integer and date data when I viewed it in LibreOffice, just to check the format of the data was OK.

Apostrophes in CSV formats are always problematic. I suspect there's a flag on the CSV generator to wrap cells with double-quotes when the content has single quotes within it. I know I've had to do that in previous work.

In T206058#5000682, @dom_walden wrote:

The only problem I saw was that it did not appear to be correctly encoding apostrophes. For example, https://eventmetrics-dev.wmflabs.org/programs/76/events/259 has cells such as "Switzerland women's national under-20 volleyball team" (effects both Title and URL columns). Perhaps similar to T215923? The encoding is correct in the wikitext format.

Yes it's the same issue as T215923. I've got a fix up for review now :)

In T206058#5007195, @MusikAnimal wrote:

Yes it's the same issue as T215923. I've got a fix up for review now :)

In that case, I will put this task into Product Sign-off as I have nothing else to do.

@MusikAnimal @dom_walden, I'm looking at the CSV report. It looks great except I notice the Creator column is missing. See screenshot below.

In T206058#5008884, @jmatazzoni wrote:

I'm looking at the CSV report. It looks great except I notice the Creator column is missing.

Done with https://github.com/wikimedia/eventmetrics/pull/213

Event details: In addition to the data/metrics, the CSV file will contain some descriptive information about the event and the report. See below under "Event details."

Event details correct for the few that I checked.

Report filename: when the user saves the report, the filename should follow this format: pages-created_event-name

I did not test this with a large range of characters, although I noticed that it supports Cyrillic. When creating an event there is some validation of the event name (e.g. not allowed "/" in names).

The default sort order will be by "Avg. daily pageviews", descending

The rows of the csv are in this order.

Wiki where the article exists. Limited to the short list of wikis defined on the Event Setup screen for the event. For space reasons, label all Wikipedias only using the language name—"Spanish," French," etc. (i.e., omit "Wikipedia"). List "Commons" and "Wikidata" as such.

@jmatazzoni Should I raise this as a separate bug? Do we also want to rename these on the "EVENT SUMMARY" and "ALL EDITS" pages (and resp. downloadable reports)?

Edits during event The edit count to the article during the event period.

@jmatazzoni Currently, this includes the edit that created the article. Perhaps after T217455 we don't want it to?

Inside the wikipedia software, we may not distinguish "edit" from "create". The organiser might know this, but if they are "[creating] reports for partners, grantors, bosses, etc." those people may not.

Bytes changed during event The net bytes changed to the page during the event period. If the Bytes Changed is a negative number, please include a - (but don't use a + for positive numbers).

I checked this for a small sample, but not systematically. I did not see any numbers which used "+". I did not see negative numbers, and I don't see how this would be possible if we are counting net bytes changed since creation. The lowest we could possibly get would be 0 (e.g. create an article then remove all the content).

Pageviews, cumulative Pageviews to the Main space page from creation until most recent data available as of the last data Update. (Granularity of Pageviews API is one day, meaning you always get yesterday's data.) If the user requests stats during the day of creation, we will show "n/a", for "not available" rather than 0, which is misleading.
Avg. daily pageviews Avg. Pageviews is an average over the preceding 30 days. If 30 days are not available, use the average of however many days are available. If the user requests stats during the day of creation (when no figures are available), we will show "n/a", for "not available" rather than 0.

Accuracy of "pageviews, cumulative" tested elsewhere (I think). I have not looked at "avg. daily pageviews" as we already know there are bugs (T217704).

@jmatazzoni If the pages created report is run on the same day as the page is created, then the columns are blank (in both csv and wikitext). Shall I raise a new bug? (example in https://eventmetrics-dev.wmflabs.org/programs/118/events/297/pages-created, but will only work today).

Incoming links A count of links to the article (cumulative, i.e., since creation)

@jmatazzoni Currently, it is only the current links to this article, rather than any page that has ever linked to this article. I assume the latter information is not available.

This has already been resolved so I assume we're all set here, but just in case:

Wiki where the article exists. Limited to the short list of wikis defined on the Event Setup screen for the event. For space reasons, label all Wikipedias only using the language name—"Spanish," French," etc. (i.e., omit "Wikipedia"). List "Commons" and "Wikidata" as such.

We don't want to do this. Using the domain en.wikipedia, commons.wikimedia, etc., is consistent with the rest of the application and avoids a bunch of API calls and logic complexity to localize "Wikipedia" etc. for the interface language. There are also tentative plans to introduce Wiktionary, Wikisource, perhaps others, into Event Metrics. In that case simply putting "Spanish" is ambiguous as it wouldn't specify the wiki family.

Edits during event The edit count to the article during the event period.

Currently, this includes the edit that created the article. Perhaps after T217455 we don't want it to?

A page creation requires an edit. I don't think this concept is the same as pages created vs improved, and all edits should be counted. That is certainly the behaviour I would expect as a user (the raw edit count would match what I see at Special:Contributions).

Incoming links A count of links to the article (cumulative, i.e., since creation)

Currently, it is only the current links to this article, rather than any page that has ever linked to this article. I assume the latter information is not available.

Correct, we can only count the current number of links to the article.