Remember that some events and programs encompass multiple wikis. It appears to be a design principle now that different wikis are separated out at the Event level @Niharika, can you explain why that was done? And do you think the fact that we are offering a wiki filter will change the need to do that?

There are multiple programs that happen on a global scale - like Wiki Loves Monuments 2018 program may have events like:

• Wiki Loves Monument 2018 - India which includes Indic wikis
• Wiki Loves Monument 2018 - North America which includes English wp

etc.
An example I could find was a program like Women in Red may have events like Women in the CEE Countries Online Editathon.

One thing we don't know for sure is that whether the event organization happens in a way that this can work. That is if the core "Women in Red" program organizers are involved in the coordination of local events like "Women in CEE countries online editathon" and would be adding those organizers to the program.

This comment is assuming #event_tools is the same as Grant-Metrics, which I think we've more or less confirmed?

Participants

• Participant username/link and for each
• User talk page
• Contributions

It'd be great to show these now. It would mean doing away with the input boxes for existing usernames, similar to what Sam was proposing at T201710#4497543. The "Categories" form follows the same design, and we have the same issue (need to do away with input boxes) because we want to link to the on-wiki category page so that the organizer can view all subcategories and pages within the categories.

• Sandbox

"Sandbox" will differ wiki to wiki. I'm not sure how we'd know where to link to?

[My idea in including Contributions and User Talk and Sandbox is that organizers could use this page during the event to monitor activity, to an extent. We could possibly even go further with that idea if we want to... ]

It needs some performance improvements (T201377) but you can use the "revision browser" to monitor event activity. We might offer per-user filtering there, so that we can see the relevant edits only (within configured categories, etc.).

In T204009#4575137, @Niharika wrote:

... There are multiple programs that happen on a global scale - like Wiki Loves Monuments 2018 program may have events like:

• Wiki Loves Monument 2018 - India which includes Indic wikis
• Wiki Loves Monument 2018 - North America which includes English wp

Thanks for the info but apparently I wasn't clear about what I was asking. Yes, it's clear there are events that encompass multiple wikis. But what isn't obvious is why the Event stats need to be separated by wiki. E.g., # of participants, bytes added, words added, etc.— i think now there are metrics presented on a per-wiki basis. But why not show just one set of sums for all the wikis added together—especially now that we're adding the ability to filter by wiki. (If I'm wrong about how the stats are presented now please tell me.)

In T204009#4577314, @jmatazzoni wrote:

In T204009#4575137, @Niharika wrote:

... There are multiple programs that happen on a global scale - like Wiki Loves Monuments 2018 program may have events like:

• Wiki Loves Monument 2018 - India which includes Indic wikis
• Wiki Loves Monument 2018 - North America which includes English wp

Thanks for the info but apparently I wasn't clear about what I was asking. Yes, it's clear there are events that encompass multiple wikis. But what isn't obvious is why the Event stats need to be separated by wiki. E.g., # of participants, bytes added, words added, etc.— i think now there are metrics presented on a per-wiki basis. But why not show just one set of sums for all the wikis added together—especially now that we're adding the ability to filter by wiki. (If I'm wrong about how the stats are presented now please tell me.)

We also show sum total across wikis. Look at this example program.

It is more useful to show per-wiki breakdowns so organizers can gauge impact across wikis. Like which wikis got a lot of participation and which ones didn't get as much. This was a quite popular feature in our testing with users. Most users asked for more information in addition to this - like being able to see which participants made the most edits or created most articles on each wiki.
There are certain metrics which make more sense across all wikis and we show those on top.

This is amazing! I'm awed by your browser prototypes. You've basically done all the frontend coding! ;)

Instead of listing things here I'm going to comment on your todo items on GitHub.

For some of the modules a small non-interactive visualization might be helpful

We do not have backend support for statistics over time, which you probably guessed. This is on the radar for retention (T189917), and if we do this we might as well make it possible to store any stat over time. Anyway, I think it's a great idea, and the static charts look really cool! Just wanted to note this would be a separate large-ish task. Everything else in the designs should be possible to implement as-is.

@Prtksxna, in response to user requests, I added to new data types to the Event Screen.

• Plays to video and audio uploads
• Gender breakdown

(I added them to the list in the Description above, for your convenience.)

One thing I overlooked:

% created page survival rate (main namespace only)

This is a fun idea! We can go by participant name to check the archive table along with page, and accurately give a raw survival rate. However we won't be able to limit to specific categories since the deleted pages won't be in the categorymembers table anymore. I would recommend showing a disclaimer ("survival rate represents all pages created by the participants, and not those within the configured categories"), or omit this metric altogether when the event has categories.

@Prtksxna, I went over event data list. It was in fact basically correct. I organized the list the way we've talked about (in categories), to make it easier to understand. Other than that, I made a very few changes in actual content and one or two to nomenclature (use the terminology listed here now). Here are the changes I made:

• I separated "Venue" (the hall or whatever) from "Location" (city/state/province)
• I think we can drop "bytes removed" from this report, as it would be ambiguous at best. We'll have to figure out what this means at some point.
• "Created page survival rate" has been renamed "New page survivial rate" (it will be obvious from the data that it's %)

I also pulled out the info below from the description. I think it does not feel like part of this report, as it has an entirely different purpose I think. We can talk about it and whether it should possibly be a separate page. Add that to your list of issues to solve. :-)

Participants

• Participant username/link and for each
• User talk page
• Sandbox
• Contributions

[My idea in including Contributions and User Talk and Sandbox is that organizers could use this page during the event to monitor activity, to an extent. We could possibly even go further with that idea if we want to... ]

"Bytes added" is a fairly meaningless figure and I'm not that happy about including it here, but I suppose Wikipedians are used to it so we will.

This number, for the record, is actually "net bytes added," which technically means it could be negative (though that is unlikely for a whole event). We can explain that and a few other things in the gloss that will accompany all the figures. E.g., this doesn't include images or other uploads but does include wikitext code.

In T204009#4612909, @jmatazzoni wrote:

"Bytes added" is a fairly meaningless figure and I'm not that happy about including it here, but I suppose Wikipedians are used to it so we will.

This number, for the record, is actually "net bytes added," which technically means it could be negative (though that is unlikely for a whole event). We can explain that and a few other things in the gloss that will accompany all the figures. E.g., this doesn't include images or other uploads but does include wikitext code.

In the past we've had a request from a couple users to see bytes added and bytes removed both. The net is probably not that useful. You might want to ask users about this.

In T204009#4616741, @Niharika wrote:

In the past we've had a request from a couple users to see bytes added and bytes removed both. The net is probably not that useful. You might want to ask users about this.

Thanks N. I agree about net bytes being a misleading figure. But @Mooeypoo indicated that net is the figure we actually get (in the API, was it?). It's the figure that is reported on Recent Changes, for example. She suggested that reporting bytes added and bytes removed would be hard.

At this point, we're looking at summary data for the whole event. So maybe it's easier to calculate for that than for some of the breakout reports? What do you guys think? Can we can but added/removed back in?

@MusikAnimal can offer more details here but my impression is that we can know for each edit whether the net byte change was positive or negative, like:

13:18  Fusible alloy‎ (diff | hist) . . (+4)‎ . . John85 (talk | contribs) (→‎Other alloys: link gold)
13:18  Ōsama Game‎ (diff | hist) . . (+374)‎ . . 191.179.124.28 (talk)
13:18  Wikipedia:Requests for adminship/Justlettersandnumbers‎‎ (2 changes | history) . . (+1,638)‎ . . [Justlettersandnumbers‎; HandsomeBoy‎]
13:18  Canadian political blogosphere‎‎ (5 changes | history) . . (-64)‎ . . [John B123‎ (5×)]

So on the whole for an event, it's fairly easy to say how many total bytes were added (4+374+1638 for this example) and total bytes removed (64 for this example). That number is not 100% accurate because that's a net for each edit but it's still a good metric to gauge edit contributions.

Of course, as Moriel pointed out, knowing the actual exact numbers is very challenging.

Yes we can get net added bytes, and optionally only count content added by the participants, within the categories, etc. We do the same such calculations at https://xtools.wmflabs.org/articleinfo. I'm pretty sure we can do it all with one query. Note however this really only tells us attempted added content. So for instance, a participant adds a whole paragraph, but because it's unsourced a patroller removes it immediately. Total added bytes is still useful to know, I think, but it may be misleading.

There is a thing called content persistence (authorship attribition), which can tell us how much content was retained. This is perhaps more useful, but not really feasible to compute on-the-fly. The WikiWho service (what we had in mind for the blame tool) already has done the work for us, but only a handful of Wikipedias are supported, and it probably would be too slow to query for events with hundreds/thousands of pages.

In T204009#4604605, @jmatazzoni wrote:

[My idea in including ... Sandbox is that organizers could use this page during the event to monitor activity, to an extent. We could possibly even go further with that idea if we want to... ]

Just wanted to reiterate that I'm not sure how we would know where the sandbox is, outside English Wikipedia. If the organizer needs to monitor activity, they can use the revision browser. We might offer filtering options there too (user, namespace, etc.).

In T204009#4596874, @MusikAnimal wrote:

One thing I overlooked:

% created page survival rate (main namespace only)

This is a fun idea! We can go by participant name to check the archive table along with page, and accurately give a raw survival rate. However we won't be able to limit to specific categories since the deleted pages won't be in the categorymembers table anymore. I would recommend showing a disclaimer ("survival rate represents all pages created by the participants, and not those within the configured categories"), or omit this metric altogether when the event has categories.

An interesting point Leon. Thanks. I'll make a note to add that to the spec.

@jmatazzoni, I've updated the mocks after our last conversation. Should we list down the things that are left to be done before we mark this task as complete?

For example — Is the filter dialog/panel design part of this task itself?

In T204009#4596874, @MusikAnimal wrote:

One thing I overlooked:

% created page survival rate (main namespace only)

This is a fun idea! We can go by participant name to check the archive table along with page, and accurately give a raw survival rate. However we won't be able to limit to specific categories since the deleted pages won't be in the categorymembers table anymore. I would recommend showing a disclaimer ("survival rate represents all pages created by the participants, and not those within the configured categories"), or omit this metric altogether when the event has categories.

Leon, we have to know the URLs of the created pages, since we are reporting on that. So if we know those, then why can't we know how many of those remain extant? Can you explain the limitation you're identifying here a little more please? Not in terms of technically why, but in terms of just how you see it playing out for the user. What is and isn't possible, in your view.

In T204009#4624226, @Prtksxna wrote:

@jmatazzoni, I've updated the mocks after our last conversation. Should we list down the things that are left to be done before we mark this task as complete?

For example — Is the filter dialog/panel design part of this task itself?

No, the paanel isn't part of this. But please make the changes from out 10/1 meeting. Thanks.

In T204009#4634180, @jmatazzoni wrote:

% created page survival rate (main namespace only)

This is a fun idea! We can go by participant name to check the archive table along with page, and accurately give a raw survival rate. However we won't be able to limit to specific categories since the deleted pages won't be in the categorymembers table anymore. I would recommend showing a disclaimer ("survival rate represents all pages created by the participants, and not those within the configured categories"), or omit this metric altogether when the event has categories.

Leon, we have to know the URLs of the created pages, since we are reporting on that. So if we know those, then why can't we know how many of those remain extant? Can you explain the limitation you're identifying here a little more please? Not in terms of technically why, but in terms of just how you see it playing out for the user. What is and isn't possible, in your view.

The issue is only if the event is configured to be within a category (or categories).

Say, the event starts at 12:00 and it's within Category:Insects. I generate stats for the first time at 12:30. During those 30 minutes, someone created an article in Category:Insects, and it was deleted. If I have the participant name, I can easily see in the archive table that they created a now-deleted article (and I can get the title of article). But I can't tell what categories it was in, because that information lives in the categorymembers table which only stores information about live pages. As far as I know there's no way around this.