• Format: The report will be downloadable as a CSV file. Do we need to let users pick a delimiter? What does Grant Metrics do now?

I'd say not for the first MVP. To make this viable, we'll need a settings page and that's out of scope.

The default order will be alphabetical [how hard is it to ignore articles and such?]

What do you mean?

Descriptive info and settings

[snip]
Location:

We aren't asking for this detail in the event creation yet, that should be in a different ticket.

Date of last data update

This is misleadingly harder than it looks; We only store the numbers in the DB, not the full information, and we are not displaying the page title and specific (per page) information yet. This means that when you hit "download", the information needs to be regenerated -- so the "last update" will always be "now."

Filter settings for download:
Article Worklist: Applied/Not applied/None supplied

We're not asking or accepting any worklist. This should be skipped (requires a separate ticket when relevant)

Categories: Applied/Not applied/None supplied + if applied, list categories [only those actually entered by the user, not subcategories included automatically]

Just a small comment -- the wikis will have to be alongside the categories, because categories related to wikis.

Participants list: Applied/Not applied/None supplied
Wikis: list

If the event has *.wikipedia.org, we display that, and not the 300+ wikis under it, right? (Verifying)

When we have filters, what is the minimum?: As we add download controls and users gain the ability to turn filters off, we'll have to face the question: what is the minimum before performance degrades too much? We've had one request from a user already to be able to turn Time Period off and just get all data about a Category, for example. This would be something that would happen on a per-download basis (i.e., not across the board for all metrics at once). Would it work? @MusikAnimal, @Mooeypoo?

We actually don't know this yet; we'll have to run some tests and figure it out as we go, especially when the level of data we're fetching is going up.

URL of the page. I don't know whether we have the ability to set default column width for downloads, but if we do there is no need to show the whole URL. [Is this possible?]

Yup, should be doable.

Description Pull from the article the first sentence, truncated to X characters [X to be determined; @Mooeypoo, what did we do in Notifications? I remember we had to increase the allotment at some point because it was too few for some scripts/languages. On English, for reference, 100 chars would be plenty. That is, of course, counting display text only, not wikitext.] If this gets too complex, we can drop but it is a useful feature for users.]]

Having a truncated text shouldn't be hard in itself, the API can give us only the beginning of the article (it would just mean a whole bunch of API requests for each page alongside the current API/sql that we're running). It might be unreasonably longer.

So, two issues with this:

1. The query can take significantly longer with this feature if there are a lot of pages. Getting the description of each page for 50,000 pages is significant.
2. Even if we truncate, we are adding a lot of text per row for the CSV file, and it could very quickly become unreasonably large. We need to check how large the csv can be as it is, but also avoid making it so big that we won't be able to produce it for the user to download.

Creator The username of the person who created the article.

Might be misleadingly harder than we think (need to check on this). I don't think the API gives us the "creator" of the article, since Wikis are inherently collaborative; we'll have to fetch the first revision and that might be expensive for edits of already existing pages.

Needs some more input. @MusikAnimal, does XTools do this?

Namespace Until we add filtering controls, this will be Main only. [Should we include it as a marker for later or leave it out?]

We'll add other namespaces later; we can either have this in but have everything with "main" or just hold off on this data point until we can allow other namespaces.

Edits during event The edit count to the article during the event period.
Edits subsequently The edit count to the article from the end of the event period until the last data update. If the event is ongoing, answer="ongoing"

We're not storing the difference or any data about this currently. If we want to add this information we'll need to start storing and seeing how to manage this.

Definitely requires engineering thinking, and a separate ticket. Perhaps will mean making this not a part of the MVP.

Same for "Bytes changes subsequently" and anything else that has "subsequently".

Words changed during event The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later.
For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable [@Mooeypoo, should I make a separate ticket to investigate this?]

This is definitely a separate ticket, and I am not sure it's that easy to do with our consideration for loads. This would mean we'll have to parse the diffs and more or less guess about words (using a space delimiter is a good start but is actually not entirely accurate, even in English :)

This is a significant change. I'd reconsider including this in the MVP. Either way, it requires a separate ticket.

Article class (where available) These rankings are available on five wikis. Each has its own ranking system and codes. Use the codes appropriate to the wiki.
For wikis where article class is unavailable, we can either 1) omit the column, which is preferred, or 2) answer=unavailable [@Mooeypoo, should I make a separate ticket to investigate this?]

Requires a separate ticket for investigation on how to do that properly, and how to make sure we are setting things up per wiki where this exists. Not trivial.

Incoming links A count as of last data update of links to the article.

Only concern: Adding loads, though if we only want a number of links, it might be okay. @MusikAnimal might have insight on this?

In T205363#4632015, @Mooeypoo wrote:

Creator The username of the person who created the article.

Might be misleadingly harder than we think (need to check on this). I don't think the API gives us the "creator" of the article, since Wikis are inherently collaborative; we'll have to fetch the first revision and that might be expensive for edits of already existing pages.

Needs some more input. @MusikAnimal, does XTools do this?

https://xtools.wmflabs.org/pages

It goes by revisions with rev_parent_id = 0, which is what we're currently doing in Event Metrics for counting the pages created. There are known caveats, such as T182183 and T192739 but for the most part it is quite accurate. I am sure you could go by MIN(rev_timestamp) but I have yet to craft such a query (please enlighten!). The new page creation log (T12331) is a bit more exacting but it also doesn't handle redirect → article and vice versa. I think this would be an uncommon scenario for event participants anyway.

Incoming links A count as of last data update of links to the article.

Only concern: Adding loads, though if we only want a number of links, it might be okay. @MusikAnimal might have insight on this?

Surprisingly it's very fast. There is an XTools API for it too, though we'll probably want to write our own query.

Article class (where available) These rankings are available on five wikis. Each has its own ranking system and codes. Use the codes appropriate to the wiki.
For wikis where article class is unavailable, we can either 1) omit the column, which is preferred, or 2) answer=unavailable [@Mooeypoo, should I make a separate ticket to investigate this?]

Requires a separate ticket for investigation on how to do that properly, and how to make sure we are setting things up per wiki where this exists. Not trivial.

Most of the dirty work has been done in XTools. You can use the project/assessments API endpoint to get a list of supported wikis and the available assessments. You can get assessments for a set of specific articles using the page/assessments endpoint, which gives you the localalized name of the article class, associated colour and icon. I believe the Dashboard is using the same API, or at least the same configuration.

Words changed during event The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later.
For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable [@Mooeypoo, should I make a separate ticket to investigate this?]

This is definitely a separate ticket, and I am not sure it's that easy to do with our consideration for loads. This would mean we'll have to parse the diffs and more or less guess about words (using a space delimiter is a good start but is actually not entirely accurate, even in English :)
This is a significant change. I'd reconsider including this in the MVP. Either way, it requires a separate ticket.

Agreed that this will slow things down noticeably. But if we do get to it, I find parsing HTML content to be more exacting in getting word counts of prose, as then it is easier to exclude things like infoboxes and references. We do the same thing in XTools, available via the page/prose API endpoint. The MediaWiki text extracts API does something similar but we do not need content, just numbers.

In T205363#4634179, @MusikAnimal wrote:

Words changed during event The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later.
For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable [@Mooeypoo, should I make a separate ticket to investigate this?]

This is definitely a separate ticket, and I am not sure it's that easy to do with our consideration for loads. This would mean we'll have to parse the diffs and more or less guess about words (using a space delimiter is a good start but is actually not entirely accurate, even in English :)
This is a significant change. I'd reconsider including this in the MVP. Either way, it requires a separate ticket.

Agreed that this will slow things down noticeably. But if we do get to it, I find parsing HTML content to be more exacting in getting word counts of prose, as then it is easier to exclude things like infoboxes and references. We do the same thing in XTools, available via the page/prose API endpoint. The MediaWiki text extracts API does something similar but we do not need content, just numbers.

I feel like this has been a long desired set of data, especially for classroom assignments where prose length is a bit more interesting than bytes (which include anything). It also helps folks measure differently considering the size of references (which on big projects, take up huge chunks of the bytes)

Have we thought at all about counting ref tags added? References are a measure of quality of content in some Wikipedias.

In T205363#4634458, @Astinson wrote:

Have we thought at all about counting ref tags added? References are a measure of quality of content in some Wikipedias.

That is, I assume, the same as citations? If so, yes, we've debated quite a bit. Counting these would be very desirable but they are not in the metadata. So we would have to parse the wikitext, which is too slow and resource intensive.

Here's an idea: Would it be useful to link to the XTools Page History tool in each row? Most of what we have listed here XTools offers, so if there's any stats in particular we have to omit for performance reasons, we can at least link to a tool where they can get that data. You can also give XTools the date range so it only shows data relevant to the event. Obviously it's preferable to have the numbers directly in the CSV export so they could do sorting and other calculations, but I assume a link is better than nothing? And of course it'd promote another Community Tech (and volunteer) tool 😉

In T205363#4634487, @jmatazzoni wrote:

In T205363#4634458, @Astinson wrote:

Have we thought at all about counting ref tags added? References are a measure of quality of content in some Wikipedias.

That is, I assume, the same as citations? If so, yes, we've debated quite a bit. Counting these would be very desirable but they are not in the metadata. So we would have to parse the wikitext, which is too slow and resource intensive.

Research is creating an event stream focused on adding urls as references, I think, in order to support work like: http://blog.archive.org/2018/10/01/more-than-9-million-broken-links-on-wikipedia-are-now-rescued/

@DarTar @Samwalton9 do you have a ticket for that yet?

T199189 and the tasks mentioned there :)

In T205363#4634179, @MusikAnimal wrote:

Agreed that this will slow things down noticeably. But if we do get to it, I find parsing HTML content to be more exacting in getting word counts of prose, as then it is easier to exclude things like infoboxes and references. We do the same thing in XTools, available via the page/prose API endpoint. The MediaWiki text extracts API does something similar but we do not need content, just numbers.

Yeah I'm not saying it's impossible, but we will need to think about how to do this while keeping performance up; my recommendation is to first go with the other metrics, make sure our performance is solid, make sure we do things in a sustainable way, and then we can take a look at either the word count and/or the counting of ref tags, etc, that require going over each diff per calculation.

In T205363#4636635, @MusikAnimal wrote:

Here's an idea: Would it be useful to link to the XTools Page History tool in each row? Most of what we have listed here XTools offers, so if there's any stats in particular we have to omit for performance reasons, we can at least link to a tool where they can get that data. You can also give XTools the date range so it only shows data relevant to the event. Obviously it's preferable to have the numbers directly in the CSV export so they could do sorting and other calculations, but I assume a link is better than nothing? And of course it'd promote another Community Tech (and volunteer) tool 😉

This seems like a smart idea, and Niharika says its' not at all hard. So I'm adding it to the document definition and to the first release (defined in T206058).

@jmatazzoni For "Edits during event" and "Bytes changed during event", I assume we want to limit it to the participants (if there are any)?

"Words added during event" can't be restricted to participants, for performance reasons.

In T205363#4945840, @MusikAnimal wrote:

@jmatazzoni For "Edits during event" and "Bytes changed during event", I assume we want to limit it to the participants (if there are any)?

"Words added during event" can't be restricted to participants, for performance reasons.

Don't look at this ticket; all the definitions and info you need should be in the CSV ticket for this report. (as I'm pretty sure it says in the ticket.)

Yes, filters should apply to all metrics, including bytes and edits. Words added has been dropped (which is why you shouldn't look at this ticket.)