Open main menu

Talk:Event Metrics

Change name of pageEdit

Hello friends, (@Shouston (WMF): @NKohli (WMF):)

Can we please change the name of this page to say "Grants metrics tool"? Because this is utterly confusing with: Grants:Metrics. Thanks, Delphine (WMF) (talk) 19:42, 13 August 2018 (UTC)

Done! -- NKohli (WMF) (talk) 20:09, 13 August 2018 (UTC)

Possible bugEdit

Hi @Rachmat04, RaymondSutanto, and Beeyan: You all are organizers for WikiLatih APG 2018 on Grant Metrics. Yesterday one of you (I think) tried to add a category on a program but it did not work and gave an error. Could you tell me which category you were trying to add? We are trying to reproduce the bug but no success so far. Thank you. :) -- NKohli (WMF) (talk) 19:20, 17 October 2018 (UTC)

Hi @NKohli (WMF): Thank you for your response. Yes, yesterday I was trying to add a participant at an event in WikiLatih APG 2018 (20180920 WikiLatih Sunda UPI) but it didn't work. Can you fix the bug? Regards, RaymondSutanto (talk) 06:39, 18 October 2018 (UTC)
@RaymondSutanto: Can you tell me which participant it was? And did you also try entering a category? We will do our best to fix the bug. :) Thanks. -- NKohli (WMF) (talk) 14:43, 18 October 2018 (UTC)
@RaymondSutanto: This should be fixed now. Sorry for the disruption! MusikAnimal (WMF) (talk) 16:53, 18 October 2018 (UTC)
@NKohli (WMF) and MusikAnimal (WMF): No, I didn't try entering a category. For the participant, yeah, it's already fixed now. Thank you for your effort! RaymondSutanto (talk) 02:15, 19 October 2018 (UTC)

What happened to Wikimetrics data?Edit

I just went to log into Wikimetrics to run a report on one of my cohorts, as I do every month or so, and it redirected me to this new tool. I logged in, and it seems to have deleted all my cohorts that I had saved in Wikimetrics. I do have them backed up on my computer, so they're not totally lost, but I'm surprised to discover this tool replaced Wikimetrics with no advance warning for Wikimetrics users. I uploaded a new cohort to Wikimetrics a couple of weeks ago and there was no banner on Wikimetrics saying it was going away. There was no message on my talk page letting me as an active user know it was going away. I'm just surprised and sad that you'd remove a tool, delete people's data, and not give any advance warning that it was happening. --LiAnna (Wiki Ed) (talk) 18:01, 26 March 2019 (UTC)

Very Sorry that this caught you by surprise but sunseting of wikimetrics was announced last month via e-mail to all individual users (plus couple e-mail lists) and has been on the plans for over a quarter, please see: https://phabricator.wikimedia.org/T211835 NRuiz (WMF) (talk) 22:42, 27 March 2019 (UTC)
Event metrics was developed to be a *better* wikimetrics which had not seen upgrades for quite a few years. Again, our apologies about this catching you by surprise.
Hmm, I definitely never got any email, and I've definitely been a user for many years (I even helped test it when Ryan Faulkner was developing it in 2013 and it was called User Metrics API!). Can you check to see if I was just overlooked, or if you have a host of users who will also be surprised when they try to use it next and discover it isn't alive anymore and all their data has been deleted? I'm wondering if there was some problem with your email notification. In the future, I'd encourage you to alert email lists where program leaders are (education, libraries, GLAM, program evaluation, etc. -- I'm subscribed to all of these but didn't see a message on any of them) if you're sunsetting a tech tool used primarily by program leaders. And please do put a banner up on the tool itself, to catch any users not subscribed to a list!
In terms of it being "better": Wikimetrics enabled me to get a specific list of which users in a cohort had made how many edits each month for a many-month stretch in a csv; this was a really valuable tool for tracking activity for months and years after the end of a program. It looks like the new Event Metrics tool is designed more to give a count of people active between 0 and 30 days after the end; that's a lot less detailed information. It also allowed me to get a daily count of how much content was added by our participants, rather than just a sum total for the program. I used this data regularly to create projection worksheets for our programs, which enabled us to project whether we were on track to meet our goals or not based on past performance. I'm sad to see a tool removed entirely in favor of one that provides much less detailed information -- and indeed, nothing that the Dashboard doesn't already give me. I will acknowledge that Wikimetrics wasn't the most intuitive app, but if you knew how to use it, it was REALLY powerful and gave you amazing data. The idea that Event Metrics in its current form is "better" than Wikimetrics in terms of the data you get is ridiculous to any Wikimetrics power user like me. --LiAnna (Wiki Ed) (talk) 04:44, 27 March 2019 (UTC)
Please do file phabricator tickets for event metrics functionality that you feel is missing, this is an example of some functionality that was added as of recent to event-metrics: https://phabricator.wikimedia.org/T217058 NRuiz (WMF) (talk) 22:42, 27 March 2019 (UTC)
Hi LiAnna (Wiki Ed), Event Metrics provides the following reports, in both csv and wikitext format (I'm linking to the tickets that define what metrics each report includes): Event Summary, which provides topline metrics for the whole event; Pages Created, which lists all new pages, along with stats about each; Pages Improved, a similar report but for all pages that were edited; and the All Edits report, which is a Recent-Changes-style, chronological record of all edits made during the event. For each report, impact metrics (like pageviews) continue indefinitely; contribution metrics are designed to follow users as long as the event is still active. I see you work with WikiEdu Foundation. It's true that Event Metrics isn't designed for an education setting, where it's important to follow students' progress as they learn. There is no per-participant breakdown of contributions or activity. But as you say, this is where the Dashboard excels. I hope that helps you understand this new tool. JMatazzoni (WMF) (talk) 17:10, 27 March 2019 (UTC)
Hi JMatazzoni (WMF), yeah, it seems like Event Metrics gives pretty much the same stats as the Dashboard, just presented in a lighter weight way for users for whom the Dashboard is overly complex for what they're trying to get, metrics-wise. All I'm saying is I wish it had been communicated that this tool was *replacing* Wikimetrics. My understanding is it was a *supplemental* new tool to have a lighter-weight alternative for event organizers for whom the Dashboard and Wikimetrics were overly complicated. That's fine, but that's not my situation. Wikimetrics provided a lot of really advanced data-reporting features that the Dashboard doesn't, and it was an important supplementary tool to the Dashboard that I used regularly. I get that you all can't maintain everything, but I just wish it had been made clear from the beginning that you were sunsetting Wikimetrics with the launch of Event Metrics. I didn't understand that from your communications about Event Metrics, and while I read about it when you announced it, it seemed like a tool for people who the current Dashboard+Wikimetrics offering wasn't working, so it didn't seem applicable to me. If I'd understood it was killing Wikimetrics, I would've participated in the discussion to document all the ways I use Wikimetrics to get vital statistics for me: in particular, per-user per-day and per-month edit counts and content added in csv form, which is not possible with the Dashboard or Event Metrics. --LiAnna (Wiki Ed) (talk) 17:47, 27 March 2019 (UTC)

@NRuiz (WMF): - Hi Nuria, quite a few people have asked me if it is still possible to get their data out of Wikimetrics? For example, old cohorts they had, so they can move them over to Event Metrics. Is that possible, or is their data lost? Some of these people are grantees who have been using Wikimetrics for a while (like our Affiliates), who had a lot of cohorts there. Thank you! ---- Shouston (WMF) (talk) 17:30, 18 April 2019 (UTC)

organisers at the event level?Edit

I tried to additional organisers to my upcoming event as I will have some local Wikipedians assisting me and could not find a way to do this. They will be adding the participants into the Event Metrics so I have to have them as organisers (right?). The only way I could find was to add them as organisers was at program level which would then give the rights over all events within the program not just the one they are supporting. Now while I have no reason to think these folk would misuse this ability, it will soon lead to many organisers existing at the program level (which I intended for all for our chapter’s events and I feel that perhaps only chapter members should have the right to create new events within our chapter’s program). I think we may need to have organisers at both the program and the event level (perhaps they could have different role names to distinguish them, say organisers and helpers) where organisers have the right to create an event within a program and then they can add helpers who have rights only over the event. Although not the situation with my upcoming event, some of our chapter events occur with regular partner organisations (mostly libraries) and they will want metrics over their events and hence their own program. With the old dashboard I can add a program into more than one campaign, so I will need to be able to associate an event with more than one program, where we have a regular partner (not so important with the more one-off events) but they will still want visibility on the metrics to their event (these will be public like with dashboard, right?). Neither of these are immediate show-stoppers but I can see that they will become issues for me sooner or later. Kerry Raymond (talk) 21:38, 31 March 2019 (UTC)

Hi Kerry Raymond. Thanks for this helpful feedback. I've created a ticket for your ideas. I'll talk about them with the team but the word I have so far is that this may be a pretty big change for Event Metrics. If that's the case, it's probably not something we'll get to in the near term. Until then, it sounds like you may have to be more strategic about how you set up Programs, so that you can give your partners and helpers access to the right events (and only those events). — JMatazzoni (WMF) (talk) 18:00, 1 April 2019 (UTC)
We have the ability in Dashboard to put a program (EM event) into multiple campaigns (EM program) so I guess I never considered this wouldn't be the model here in EM. It meant we could have a campaign like 1Lib1Ref2019 with all the individual libraries having programs with in, but at the same time, the libraries could also be under their own Library Campaign where they have other Wikipedia activity. We have partners that want to see the whole of their activity at a glance [1]. But equally we have Wikimedia Australia which has an obligation to report to WMF for grant money so we need an easy way to show all of our events. Unlike some lucky chapters, we have no paid staff who can be asked to do the administrative work for reporting. We are all volunteers who already give up a lot of our time both on-wiki and doing outreach and I frankly don't want to increase my workload by now having to do manual aggregation across all events split across partner programs. EM is supposed to support WMF's demand for metrics and WMF wants us to form strong partnerships. Please make it possible for us to meet both expectations. Kerry Raymond (talk) 01:59, 2 April 2019 (UTC)

Migrating from dashboard to new eventmetricsEdit

I’ve got a couple of long-running ongoing programs on dashboard, plus obviously some historic ones. going forward, are we going to be able to migrate these over to event metrics? or will dashboard continue to be maintained? The problem is that regular partner organisations like to report (boast) about their impact metrics so I need those page views to keep growing for both their current and historic programs/events and so I don’t want to lose their past or currently ongoing activities’s metrics and ideally have all events past, current and future accessible to them through a single system not split across two systems. i’m less concerned about migrating old events that don’t involve partners but our partners are very important to our events due to our geography. Again this is not an immediate problem but will probably become so sooner or later. Kerry Raymond (talk) 21:38, 31 March 2019 (UTC)

Kerry Raymond: see more details below, but the Dashboard is definitely still going to be maintained. An API ought to be possible, so that Dashboard users could automatically get Event Metrics stats as well, but that feature is in the "freezer" and isn't planned for implementation.--Sage (Wiki Ed) (talk) 17:36, 1 April 2019 (UTC)

Event Metrics versus DashboardEdit

Would the Event Metrics replace entirely the Dashboard ? If that what is planned, I have a couple of essential elements on the dashboard that I would miss here, namely

  • the list of articles suggested and attribution of such suggestions to participants (or adoption by) : whilst it is not a MUST HAVE, it will be a serious loss not to have this feature anymore
  • the possibility for ANY person to create an event and link it to an already existing overarching program. For example... how would we run big campaigns such as WikiGap ? the official organizers would become bottleneck as we would have to contact them to ask them to create the event for us and put us as event organizers.
  • the possibility for ANY person to see what's going on within a campaign. I do not see any means planned to do that. In the current tool, I have no mean of knowing that there is a WikiGap program ongoing for example and no way to see how many events are registered within. And no way to download general stats from a campaign or an event I am not organizer of.

All those features are missing in the current Event Metrics.

So now... IF the Event Metrics tool is going to operate along with the dashboard, would that mean that we would have to manually duplicate things ? As in entering events, date, participants in both tools ? If that is the case, then we would probably need to have a system to replicate the events to save us time.

I reserve my other comments till I understand better what would happen to the dashboard when the Event Metrics tool is done. Anthere (talk) 10:52, 1 April 2019 (UTC)

Here are a few more current dashboard features that I think are also essential:
  • Alerts on articles that are currently under some form of deletion review. See for example: [2]
  • The ability to create accounts via this tool, and have them automatically be attached to said event/program. See this video on commons around/after 01:07:00 for How to create accounts with dashboard.
  • The ability for an event to belong to two campaigns - it is unclear to me if this is possible with the current tool
As far as I can tell, these are missing from this tool. As I have previously stated on the talk page, and in interviews: as the group conducting the largest campaigns on Dashboard, Art+Feminism is unable to use this tool until these features are added, as they are core to our organizational process. --Theredproject (talk) 14:40, 1 April 2019 (UTC)
Just realized I never used the account creation tool... thanks for the link ! Anthere (talk)

Programs & Events Dashboard will continue to be supported by Wiki EducationEdit

Anthere: Programs & Events Dashboard has been developed and maintained by Wiki Education, and we plan to continue supporting it in the long term; it runs the same software as our own dashboard.wikiedu.org site, and we're committed to making the work we put into that as useful as we can for the rest of the global community as well. The last time I talked with JMatazzoni_(WMF) about the relationship between the two projects, my impression was that Event Metrics will be focused on metrics and reporting rather than program organizing tools, while the Dashboard is significantly focused on the program organizing and monitoring side of things. Event Metrics has a more limited scope, and may be good option for people who only need to get the numbers without worrying about things like keeping track of which users are working on which articles, what the timeline of the event is, account creation, training modules, and other more specialized features of the Dashboard. (Joe, please jump in if that doesn't match your take.)

I've been advocating for an Event Metrics API, such that Event Metrics stats could automatically be generated for any Dashboard program (once we update the Dashboard to hook into this API). That way, no one would need to duplicate their work setting up a program on both tools or miss out on any additional metrics from Event Metrics if they are using the Dashboard. That didn't make the cut for this first version, but I hope it will be a priority if/when additional work is done to extend it.

For the future of the Dashboard, we're going to continue working on features that make it easier to organize, run, and track whatever types of programs people are running. As of 2019, work is accellerating: Wiki Education now has two staff primarily focused on building the Dashboard — myself and Wes Reid — and we've got tentative plans around improvements specifically for global Wikipedia Education Program courses and for better stats support for non-Wikipedia wikis. We're also likely to add support for `references added` stats (including for Wikidata!) in the coming months. (Suggestions and questions always welcome at Talk:Programs & Events Dashboard.)--Sage (Wiki Ed) (talk) 17:30, 1 April 2019 (UTC)

Those are excellent news Sage. I also support an Event Metrics API now :) I will look again at the Event Metrics tool tomorrow. Anthere (talk)
A little late to the party on this, but yes, I'd welcome the integration of an API such that the useful Event Metrics stats could be auto generated for any Dashboard programme - at the moment I'm going to be looking at having to create the event in both EM & P&ED which.... isn't great. Lirazelf (talk) 08:04, 7 May 2019 (UTC)

TestingEdit

Hi Joe,

I took it out for a spin, with the idea of seeing whether I could replicate the annual report for WikiProject Medicine, which is usually organized by User:Doc James, to see how things were going for the first quarter of 2019.

Bottom line: No, and that's not just because it still says "Please wait, currently crunching the numbers..." (for ~25 minutes so far).

The setup process isn't impossible, although there are a few quirks. Here are a few notes from that:

Hi Whatamidoing (WMF). Thanks for this detailed input. I will preface my point-by-point comments below with a general note about where we are in the process now. CommTech, as many people know, is tasked with addressing the top-10 wishes from each year’s Community Wishlist. That means the average CommTech project needs to be relatively short—averaging out to about a month. This project, a large one already for us in terms of effort and features, is a holdover from the last year's Wishlist, so the team will be moving on from it after April 15. We need to bring our wish-granting efforts to new groups of deserving users (in particular, we need to get started on this year’s list).  So at this point, we are not entertaining new feature requests, but looking for things that are really broken. Having set that frame of reference, let me respond do your issues in turn. JMatazzoni (WMF) (talk) 22:29, 1 April 2019 (UTC)
  • I want to be able to use "enwiki" (abbreviations that the config files use) instead of en.wikipedia. Also, I want to be able to search for names, like typing "English" (works in Compact Language Links). Alternatively, maybe we could use separate drop downs for project (Wikipedia, Wikivoyage, etc.) and language (English, German, etc.), so I can find my target wikis in a list.
    • See my answer above; i.e., this would be nice but we're devoting our efforts at this point to fixing critical problems. —JM
  • Please default to UTC tiimezone (not browser time). That's the default for timestamps on the wikis.
    • I’m not sure I agree with your premise. When I create an event, it’s quite likely that it will take place in my local area. So using my local timezone seems valid and convenient. To switch the timezone to UTC, users need only type a “u” into the field: the menu will scroll directly to the UTC option. —JM
      • That depends upon whether your event is "two hours at this library" or "all month". Whatamidoing (WMF) (talk) 22:59, 2 April 2019 (UTC)
  • On the next screen, I discovered that it doesn't work on talk page categories (to produce results for article edits), which means that I can't do what I want, which was to track anyone who changed any article with a given set of talk-page categories.
    • Talk-page Category filtering was a feature we really wanted to add. But it turns out to be somewhat tricky with a potential for significant impact on performance, so we weren’t able to sort it out in time. You can filter using hidden categories. So depending on the policies of the wiki in question, that should provide a solution for some. — JM

Well, that's okay; I'll fall back to the list of WPMED participants. However, that introduced two problems that User:Harej will want to know about:

    1. A bot removes people's names from w:en:Wikipedia:WikiProject Medicine/Members if they haven't edited for >30 days, which means that I can't use that list to run a quarterly report.
    2. There's no way to extract just the usernames from this list, except by copying the whole thing and stripping out all the extraneous stuff.
      • The program can do some stripping of extra characters, like underscores and extra spaces. It can even handle a list like this with no problem. But the list you link to is pretty heterogenous. —JM
  • But now that I know that my list of usernames excludes people who edited in January or February, but not March, I don't know whether I can go back to the previous step and change my dates.
    • Yes, you can always change your dates. —JM
  • The next step was to discover that three of the 94 usernames were invalid. This was the most confusing part of the process. The error message said "3 usernames are invalid. Please edit or remove and then re-submit to save. Check for incorrect spelling, capitalization and extra formatting." Here's what I learned:
    1. It thinks Doc_James is different from Doc James. This makes it hard to copy usernames from URLs.
    • In my tests, the system accepts both “Doc James” and “Doc_James” equally. You can even put them both in and the system de-duplicates. —JM
    1. It can't handle renamed accounts or redirects to usernames.
      • Correct. You have to enter a valid name. —JM
    2. When you correct a name, it doesn't remove the red warning triangle.
      • When you correct a name, the error messages will be cleared only when you Save. You do get some validation: when you start entering the name, the username menu fives feedback in the form of listeing valid names. —JM
    3. I don't know what to do after correcting the three usernames. Eventually it turned out that I needed to click the button to save the names again.
      • Yes, you need to Save for the system to clear the errors. I wish it were otherwise too. The big red banner does say what you need to do: maybe that message could be more clearly worded? —JM
        • That might help, but the likelihood of looking back at the top of the page when my problem is in this one little tiny spot might be low. Perhaps a (i) button or some hovertext? Whatamidoing (WMF) (talk) 22:59, 2 April 2019 (UTC)
  • Now we enter purgatory: How long should I wait? I know it will eventually time out, but does that happen in five minutes or five hours? If I think my query might be large, could I have a button to just get whatever metrics are the easiest to calculate? Or maybe a button to submit my query as a low-priority report, and it can e-mail me (or something like that) when it's done? I don't know if I should be leaving the tab open longer, or if it timed out 20 minutes ago and never told me.
    • Thanks for filing a ticket about that delay. We're evaluating the system's performance now, and encourage people to report issues of this type. It's very helpful. At a minimum, you should get clearer messaging. We will investigate. —JM

Whatamidoing (WMF) (talk) 18:53, 1 April 2019 (UTC)

Being able to track all medical editors as an "event" could be interesting. Doc James (talk · contribs · email) 21:11, 1 April 2019 (UTC)
Hi Doc James. Event Metrics may not have the power to track all medical editors. It would probably time out. You'd need to break them up somehow— by subject specialty, for example. That's what the Category filters are meant to do (help page). You can't use talk page categories, unfortunately (a feature I'd really wanted to add), but you can use hidden categories. I'd like to see that experiment; let me know if you try. —JMatazzoni (WMF) (talk) 16:16, 2 April 2019 (UTC)
User:Whatamidoing (WMF) we have "Category:RTT" which is a hidden category of some 1200 of WPMEDs most read articles. It is the category that the Translation task force runs on. Doc James (talk · contribs · email) 18:59, 2 April 2019 (UTC)
Hi Doc James. I created an event for your hidden RTT category. I went for broke and tracked the whole of 2018. I'm happy to report that setup took under a minute (it's just one category, after all) and processing took about 5 minutes. Below is a screenshot of the results. As you can see, those are popular articles indeed—viewed 1.4 million times a day and kept up to date by some 5,500 contributors! —JMatazzoni (WMF) (talk) 21:31, 2 April 2019 (UTC)
 
Contributions to the hidden category RTT in 2018. The articles in this category are viewed 1.4 million times a day.
Wonderful thanks User:JMatazzoni (WMF). Will look at this more soon. Yes they get just over half a billion pageviews a year :-) Doc James (talk · contribs · email) 21:37, 2 April 2019 (UTC)
My pleasure Doc James. I made you an "organizer" in the RTT event mentioned above, so you can have a look and maybe download a report. I hope you get a chance to give it a try. JMatazzoni (WMF) (talk) 21:51, 2 April 2019 (UTC)
The tool gives the 5,500 participants. Is it possible to get a list ranked by number of edits? Can we break bytes changed into "added" and "removed"? And what proportion are reverts? Were the size of the edit just before or after is the exact opposite? Doc James (talk · contribs · email) 23:07, 2 April 2019 (UTC)

Total pageviews vs daily averagesEdit

I think partner orgs would much rather see total pageviews than daily averages. They like the big numbers you get from total pageviews and frankly it’s the gift that keeps on giving as it increases as each day passes. For what purpose does anyone want average daily ones? You can’t use them to compare between events because different articles have naturally different popularity and hence page views. And if WMF did anything to signal that they were rewarding high daily averages, the obvious way to game the system would be to work on very popular articles at events, which would be the worst place to start beginners. A sensible beginner strategy is to stay in the quieter backwaters. Given the wildly varying nature of events, I doubt they are comparable by any metric. Even in Evnts I run I would expect different outcomes with different groups. Bring back total page views! Kerry Raymond (talk) 06:37, 5 April 2019 (UTC)

Hi Kerry Raymond. Thanks for your feedback. I'm glad you brought this up. I get it that big pageview stats can be very encouraging for participants, partners and sponsors. But where counting pageviews accumulated since article creation is the obvious way to go for Pages Created, the case is different for Uploaded Files and Pages Improved. Counting pageviews since creation of articles that event participants didn't create would not be meaningful, so we had to find an alternative. The two cases differ somewhat, however, so let me take them separately.
For Uploaded Files, the goal was to give a count for all the articles on all wikis on which Uploaded Files have been placed. There's a log of all the articles where a file is placed, so we're good there. But unfortunately the wikis don't log the dates on which the files landed on the various articles. So there's no easy way to count the actual pageviews to the files. That's why we came up with the idea of average daily views. It's an average of the most recent 31 days, so though it doesn't tell you the cumulative total, it gives a good picture of the current rate of accumulation—which a person can certainly project forward in a rough way.
For Pages Improved, it should theoretically be possible to count forward from the first edit to a given page of the event to get a cumulative total of all the times that page was viewed after it was worked on during the event. But doing so is a somewhat intensive operation, and the team has been worried about performance of the system in general. Event Metrics is doing a lot already, and a lot of things that are new, and there have been reports (e.g., this ticket or this one) of it struggling with larger events. So we have to work those out before we can think about adding to the load. In the meanwhile, I hope the pageview average figures will prove useful. —JMatazzoni (WMF) (talk) 21:28, 5 April 2019 (UTC)
I have previously pointed out that we can store past totals and just add to them. We don’t have to recompute the lot every time. It’s a performance problem that can be solved. Events are all about participants, partners and sponsors, who else are we trying to keep engaged and happy? If the metrics are not for them, who else is wanting them and for what purpose? Kerry Raymond (talk) 06:06, 6 April 2019 (UTC)
The presumption here seems to be that events generally create new articles. This may be true of edit-a-thons but not of events like 1Lib1Ref. Even with edit-a-thons, because of the restrictions on new users creating new articles, I sometimes create the stubs and let the participants expand them. As I am not included in the participant list, these articles won't be tracked. I usually do not include myself in event participant lists because if I did, they would pick up all my normal editing during the event window, which would over-inflate the metrics. One of the things we try to avoid with new users is getting them to start new articles (because it often ends badly and erodes their confidence) so with new users it is preferable to have them expand existing articles not creating new ones but we need exactly the same metrics. I appeciate the issue with photos is different, but even so BaGKAM2 seems to be able to do it. Kerry Raymond (talk) 00:48, 7 April 2019 (UTC)
Hi Kerry Raymond. It's clear to me that event participants generally do a lot more page "improving" than "creating." And rightly so, for the reasons you cite. The issue is how to get a meaningful metric about pages that were improved but not created during the event. I think "Average daily views to pages improved" is useful and provides insight. It would be nice to be able add a cumulative metric as well, to track each page improved from the first edit to it of the event. And that should be possible theoretically. But right now we can't do anything to increase system load since we're still seeing performance issues on larger events (we are working to optimize this). Such a metric should be possible in future, though we probably wont' have the bandwidth to add it as part of this project, since we need to be moving on to start granting 2019 wishes very soon. Still, the team has discussed it, and I will write up a ticket to make sure we capture the idea. — JMatazzoni (WMF) (talk) 00:02, 9 April 2019 (UTC)
Then, could we just multiply the "Average daily views to pages improved" by the number of days since the event started and use that as a "estimage total for improved pages"? Combine it with the total views for pages created and we have the "big number we really like to see". A bit rough and ready but it's fast to perform. It does have the risk that if the average daily views drop, then the overall total will drop but the number of months would be increasing, so you'd hope it would keep the total going up overall (although it's possible it would fall). Kerry Raymond (talk) 02:06, 9 April 2019 (UTC)
Hi Kerry Raymond. If a rough-and-ready metric would suit, then the one that makes sense to me is something I might call "Views to pages improved (since the event)". (I'll keep working on that name.) We could simply count forward from the start of the event. That way we wouldn't have to first determine the date and time of the first edit for each page and count each page differently. Would that work for you? Also, do you need this metric for each article in the Pages Improved report, or could we start by just adding it to the Event Summary report for a grand total? —JMatazzoni (WMF) (talk) 16:48, 9 April 2019 (UTC)
Well, my partner experience suggests one grand total of page views will do just fine (the bigger the number, the better) but others may think differently. Kerry Raymond (talk) 07:06, 10 April 2019 (UTC)

The mystery of the missing participant and their missing editsEdit

Having wanted to send out some thank you messages to the participants, I went to grab the list of user names from Event Metrics and discovered that, while I could add in a list of Participants, I couldn't get it back out again as the users are listed individually and no attempt to copy seemed to be able to span the list as displayed on my screen. So I thought, OK, I'll get the CSV and extract it from there (as in strip it down to the Participants column and then remove the duplicates). But no, that doesn't work either. It returns 22 participants and not 23 as claimed on main Event Metrics screen. Eventually, after poking around comparing the CSV edits against User contributions, I realised that the CSV isn't including all edits but only mainspace edits on WP and File space edits on Commons and that's why one user didn't appear as it seems they never made a main space edit (a fact it would have been useful for me to know at the event!). I understand (and prefer) that the displayed metrics relate to only specified name spaces, but the CSV of edits does need to include everything for the benefit of the event organiser. I shouldn't have to go to that much messing around to find the missing participant. As a corollory to this, I am wondering if we have another problem. New articles by new users are going to be in Draft. If the event organisers wait for Articles for Creation reviewers to accept the articles (a process that can take weeks), then am I right in thinking that no metrics will appear for those articles until they are accepted? As I am an AfC reviewer, I accepted all of the articles at the end of the event so they were in main space, so there was nothing left in Draft, so I cannot easily test myself what happens if articles are left in Draft. But again, forgetting about the metrics, as an event organiser, I do need to know if there are articles sitting either in Draft or the User sandbox (or any other random place that new users may write things -- and you do occasionally get some weird places). The organiser can't easily deal with any of any of these scenarios if the CSV omits edits to other namespaces. It would be much better to include all edits but add a namespace column so it is easy to filter out the ones you aren't interested in for whatever purpose (which would include the calculations of the public metrics). Kerry Raymond (talk) 01:24, 7 April 2019 (UTC)

comparingEdit

first real spin in the tool. I'm comparing my Outreach Dashboard to my Metrics totals and they are definitely different. Also where do I add other language wikis? I tried to add sp.wikipedia to no avail. Just poking around for now. Thanks!Heathart (talk) 03:25, 8 April 2019 (UTC) cc:@Raggachampiongirl:

Hi Heathart and @Raggachampiongirl: To add another wiki, click the Settings button and then click "+Add wiki." You have to know the language abbreviations, which is less than ideal, though auto-complete should help. (E.g., Spanish, if that's what you're looking for, is es.wikipedia rather than sp.wikipedia—because Español!)
If the numbers are different from other programs, perhaps we made different assumptions in defining the metrics. E.g., a lot of metrics count main namespace changes only. Each number has a little "i" info icon next to it on the Summary page that you can hover over for an explanation. Or the Help pages have a whole page for Definitions of metrics. I hope that helps. —JMatazzoni (WMF) (talk) 21:41, 8 April 2019 (UTC)

Drafts at the end of eventsEdit

Further to my thinking about drafts at the end of events, maybe we need to show "short-term metrics" and "long-term metrics". Clearly in the long run, it's really only mainspace metrics that matter and their impact. But while the event is in progress (or in the AfC reviewing lag), we really need "short-term metrics" to motivate the troops/partner/host/sponsor and to let the organiser stay on top of a rapidly evolving situation. For example, at run-time, the organiser needs to know what articles are developing in Draft and User Space, and we probably need an easy way to provide a list of articles from an event that need AfC review. If event organisers are not AfC reviewers, sitting back and waiting for AfC to run its course both takes forever to happen and almost certainly involves an infinite cycle of rejection (for reasons that mystify many of us, the standard at AfC is far higher than the standard to survive AfD). Every event needs an AfC reviewer standing by (whether on the ground or shortly afterwards on-line) to consider acceptance of drafts to mainspace; letting AfC run its natural course is a disaster for an event. So therefore it might be useful if friendly AfC reviewers could be pointed at an event and easily get a list of what needs reviewing to try to get as many as possible into mainspace ASAP. Realistically most event participants do not continue to edit after the event. Most will not even be logged in so won't see any dialogue in relation to their AfC submission. Also many event participants will not even click the Submit for Review button, so that's another thing event organisers must do. Again, metrics could help if the status of drafts can be split into "not yet submitted for review" and "submitted for review". It would nice if events were all as simple as people like to imagine they are (just a bunch of folks doing some edits, creating some articles), but in fact, organising a good event is a complex matter of managing a truckload of risks, especially when new/occasional participants are involved. So anything event metrics can do to draw event organisers attention to "problems to be sorted out" is highly beneficial to the event's success. It highlights the difference between short-term input metrics needs (how is the event going) and long-term impact metrics (what was achieved). The purposes are very different; in the short-term the metrics need to expose problems while in the long-term metrics need to focus on success. Kerry Raymond (talk) 00:23, 9 April 2019 (UTC)

Things failing to work?!Edit

I created [3] with 8 categories and 5 participants. The summaries, after crunching the numbers, appeared to specifically exclude the categories (and/or) to exclude the wiki (enwiki) of which they were part. I thought I would simply remove the categories (and wished to remove some participants at the same time), which gave me 2 participants and 0 categories. When crunched with the new settings, I learned that just one article had been created. Yet I know that within the time period I had created at least four articles.... Is it just unhappy with resetting the settings, because, certainly, at least some of the numbers are wrong. Cheers, MargaretRDonald (talk) 20:41, 27 July 2019 (UTC) I forgot to add. At no time has it given correct numbers for uploads to commons. MargaretRDonald (talk) 20:44, 27 July 2019 (UTC)

Return to "Event Metrics" page.