Done. You should be able to track any mad and nia wikis now. Let me know if you run into any trouble.

In T273797#6812060, @JTannerWMF wrote:

In our Board Refinement meeting we discussed converting to webview in instances that we take users out of the app, once we do that it should fix this case.

It looks like it was in a state of intermittent failure, with some requests resolving and some returning a 500. I've restarted the server, which usually fixes this. Any help diagnosing the root cause would be appreciated, as I haven't been able to find it so far, and this has happened a handful of times in recent months.

My goal with the current approach was to make it possible to recreate all the kinds of slide content the Wiki Education Dashboard uses, but have it be editable and translateable on Meta. On the Dashboard, a slide record has separate fields for title, content, and quiz, and the quiz field is has a specific structure of question, answers, and explanations. Using the HTML from a Meta page might work for basic slides, but it would be more difficult to also include quizzes.

I've added more explanation of supported wikitext here: https://meta.wikimedia.org/wiki/Programs_%26_Events_Dashboard/Using_the_Dashboard#Supported_wikitext

Disk was full. I deleted 3 GB worth of log files and restarted the system.

It sounds like the 'Article Scoped Program' mode may be what you want to use. With that program type, only assigned articles are tracked at all.

Anyone with admin rights on the dashboard can add a new facilitator to any course. The best option is probably for someone at WMSE to get admin rights, and then if the need to copy a course comes up, they can add the apprlopriate staff member so that it can be copied.

I upgraded the Ruby version from 2.5.0 to 2.7.1. Downtime was minimal, perhaps a few minutes.

Further investigation of those problems pointed to running out of memory almost certainly being the root of it; we confirmed that when a Sidekiq worker process runs out of memory, it does indeed result in an 'orphan lock' which stopped the active job from being rescheduled.

Yes, the UX for that should be improved; we have an open issue for it here: https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/1760

There is no ig.wiktionary.org; it redirects to Incubator.

Yep, this shouldn't happen anymore!

@Theklan is there another one where this happened? It looks like that one shows edits now, although it didn't earlier today. All the edits from that user are pretty recent, though.

The system got into that bad state again, where requests intermittently fail.

@cahyo.ramadhani it's counting Gorontalo edits now!

@MusikAnimal thank you! It looks like the old hostnames have continued to work, as we never updated that PHP endpoint on labs until now. I guess the old names were left in place, they just aren't being created for new wikis.

@MusikAnimal any quick ideas about why connecting to the gorwiki database isn't working like others?

Hmm.... It looks like the query service we use to import revisions from the labs replica database isn't working for gor.wikipedia like it does for other wikis.

In T191813#6126905, @Samwalton9 wrote:

This could be related to something we've been seeing where Puppet runs have been eating the resources of the Library Card Platform, we had to upgrade our instance size.

I'm investigating errors that have been happening often in recent weeks... the Dashboard becomes unavailable, returning an Apache server error message when users try to load the site. (Typically, a server error in the Rails code results in rendering the Rails error template rather than the Apache one.) It seems like this usually happens in the middle of the night between Sunday and Monday.

This has been happening somewhat often recently, perhaps once a week or so. I haven't been able to find the cause, so if anyone good with Apache and/or Rails apps wants to help out, that would be most welcome.

Thank you! Are there any big hurdles to me being able to re-run an analysis like this myself in the future?

Hi! If you sent me your email address, I can invite you to the project Slack where you can ask for help if you run into any trouble setting it up. Here are the setup instructions: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/docs/setup.md

It looks like all the issues from the initial description, at least, are resolved. If there's anything left that is still not working translation-wise, please open a new task.

@DDJJ this data can be downloaded in a CSV. If you click 'Download stats' and then 'Overview data', you can find the total number of newly registered editors. The 'Editors data' CSV includes data for each individual account, including whether it is a newly registered one.

Hi @Mh-3110 ! If you send me an email address, I can invite you to the development Slack for the Dashboard. Let me know if you have any questions or run into problems getting the environment set up.

Lovely!

@cchen @kzimmerman @nshahquinn-wmf I've deployed the change, so the CSVs should be scrapable again now.

I will remove the login requirement for the participants CSV downloads. We added that to prevent bots from crawling those too often (since some of them take a while and tie up system resources), but I can figure out a better way to solve that problem. I should have it ready later today so that it can be scraped again.

In T244587#5919009, @Eric_Luth_WMSE wrote:

when it comes to the hashtag question, I am probably a bit to unaccostomed to Dashboard to understand how it would be integrated? I know how to search for a hashtag through quarry, but can I see hashtags in dashboard? Is there any documentation of how that works?
(@Alicia_Fagerving_WMSE @Ragesoss )

I'm not sure what was going wrong previously, as it looks like it's been updating without any obvious errors since yesterday. It might have been a problem with the labs replica database being overwhelmed.

Yes, a utf8mb4 problem. Tracked here as well: https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/1744

I'm looking into this; I've added update debugging for this program to see if I can learn what might be going wrong. My guess at this point is that the very large collection of articles from PetScan is pushing the system beyond what it can handle, but I'm not yet sure where the bottleneck is exactly.

I've just deployed a fix for this. Now the CSV should only include the articles that are tracked.

Thanks for reporting this @Alicia_Fagerving_WMSE. We'll look into it soon. The references count is based on the item's features as interpreted by ORES, so this might indicate a bug with the ORES system or a bug in the Dashboard... I'm not yet sure which.

In T240351#5818983, @GoranSMilovanovic wrote:

@Ragesoss When we learn what training modules were used in this campaign, I hope you will be able to share the data sets with me via email (goran.milovanovic_ext@wikimedia.de)? Thank you.

@Aklapper they received the confirmation emails, and just now one of them triggered a new confirmation email via Special:Preferences which again gave the 'invalid confirmation code' message after following the link.

Fixed via https://github.com/WikiEducationFoundation/WikiEduDashboard/commit/613611c324338b82d44c5cfe93c109b4b4f8b357

Done!

I'm working on it. I've replaced the women-in-red instance with a tool, and will probably be able to delete the instance soon. I'm just starting the process of setting up a replacement Buster server for the backups one.

I would love if that indication got added upstream, so that I could add the same kind of warning of incomplete results to the authorship highlighting feature on Wiki Education Dashboard (which is where we noticed my example).

This edit fixed the above example: https://en.wikipedia.org/w/index.php?title=Pathogen&action=historysubmit&type=revision&diff=928093084&oldid=927736310

Another example of where it breaks midway through the page is here: https://en.wikipedia.org/wiki/Pathogen#Viruses

That log file is not needed at all. It looks like that logging is part of the automatic configuration for a web tool with lighttpd, but I can't find any documentation on how to disable it or automatically truncate it when it gets big. All I found is: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Lighttpd#Web_logs

This project shifted focus somewhat in the final propoal, but it's complete.

@Theklan thanks for the ping! Amit added tracking for some additional namespaces enabled now, although it doesn't count them for the main statistics. But we don't yet have support for the special es and eu namespaces you're asking for.

I'm hoping that @Amitjoki will be able to get to this during his GSoC project. He's got some other things that will need to be completed first, but he's making solid progress so far.

I modified the apache configuration today to reduce the amount of logging and avoid storing IP addresses:

• Removed access logging from the dashboard vhost
• Disabled other-vhosts-access-log.conf
• edited to the ErrorLog configuration of apache2.conf to remove %h %l %u from the format, so that no user information is stored for errors.
• deleted old logs

@Ata this happens when we introduce new messages; it's because your browser is still using an older cached version of the interface message file. Performing a hard refresh should fix it.

@Rfarrand yes, I can do this.

Yes, I'll be there and so will Wes Reid.

I enabled it for translation and updated it: https://outreachdashboard.wmflabs.org/training/editing-wikipedia/wikipedia-essentials

For that example, this is the page that needs to be set up for translation and then translated: https://meta.wikimedia.org/wiki/Training_modules/wikipedia-essentials

@Theklan If you go to the 'wiki source' page for the module from the link at the end of the table of contents — for the example above, https://meta.wikimedia.org/wiki/User:JSutherland_(WMF)/dashboard_modules/keeping_events_safe.json — then you can see the "wiki_page" that contains the title and description of the module: https://meta.wikimedia.org/wiki/Training_modules/Keeping_events_safe/description

Took a while to get to it, but this shipped a few months ago.

I think the Single Table Inheritance approach to course types has worked pretty well; looking back on this now, I don't think there's anything I'd want to majorly change.

These should be all taken care of. If there are any left, please reopen.

The title and module description can be translated now. See, for example, https://outreachdashboard.wmflabs.org/training/support-and-safety/keeping-events-safe?locale=fr

This has been available for a while.

It looks like this is okay now? Please reopen and provide a screenshot of the problem if not.

This is done, and can be enabled for additional wikis per https://meta.wikimedia.org/wiki/Programs_%26_Events_Dashboard#Enabling_automatic_edits_on_a_new_wiki

Not really relevant anymore.

Private events have been available for a while now.

I think this is sorted out now.

I think this has been working fine for a while now; if there are any related problems, please reopen this and describe what is wrong.

Not considering yanking out React at this point; we've done some architecture improvements that make it easier to work with, including the switch to Redux for state management, and it's relatively accessible to new devs who know the basics of React now (and there are lots of those).

Not enough info to know whether this is a Dashboard issue or outside our control.

This was fixed a while ago.

This was fixed some time ago.