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.

This was fixed a while ago.

It's well past 'beta' now.

For the last two days or so, many spam Campaign records were being created, because of a security hole that allowed a not-logged-in user to create a Campaign.

@Aklapper The application was submitted on the Outreachy website then, it just didn't have a Phabricator version posted.

The Dashboard went down when the disk filled up. https://phabricator.wikimedia.org/T219865

The disk was full. I've fixed it for now, and will look into preventing that particular problem soon.

I'm deploying a fix for this: https://github.com/WikiEducationFoundation/WikiEduDashboard/commit/fc1dc9a0b398e6f97d636c9628fd8ae2881f2504

@Madhurgupta10 sure, sounds good.

@zaisid either one of those, although it's probably too late this round for totally separate project ideas.

Hi @Jcnitdgp25. See the note I just added to the end of the task description.

Done! We had the server up and configured two weeks ago and did the switchover, and I just did the final step of destroying the Ubuntu instance.

@srishakatux I added this on the Outreachy site also, where it's pending approval.

@Batrapunit hi! I've just updated the description with some general information to help you get started.

Wes and I spent today getting a new debian server spun up, configured, and set for deployment. We got the app up and running, so what remains to be done is:

• Put up a notice about pending downtime
• Disable the old server
• Create a mysql dump
• Load the dump on new server
• Redirect outreachdashboard.wmflabs.org to the new server
• Verify that things are working smoothly
• Destroy the old server

@Theklan thanks! I think it's likely that we'll be improving cross-wiki support as well as additional namespace support for the Dashboard this summer, partly through a Google Summer of Code project.

Thanks @Jdforrester-WMF !

Currently, the only way to pull that data is to have server access, and run the above ruby code from a server console. It's a quick task, so I think it'll be easier to keep doing it this way for now, but at some point we could build an easier way to generate this data on demand.

Thanks @Krenair. What will it mean for Ubuntu support to be removed?

Wiki Education articles aren't necessarily representative in terms of the likelihood of having markup edge cases, but my rough guess based on that would be about 1 in 40 articles. It's probably higher in the general article population from lists and other table-heavy article genres that our student editors don't work on as often (and probably higher on well-developed articles, since they'll have more markup and more complex markup).

I've just pulled the data, and will send it by email shortly.

Wiki Education has been using the WhoColor API on the Dashboard for a while now, and I can report how it's been received by our users — mostly instructors who are using it for reviewing the work that their students have done on existing articles. Here's an example of it in action: https://dashboard.wikiedu.org/courses/University_of_Chicago/Censorship_and_Information_Control_During_Information_Revolutions_(Autumn)/articles?showArticle=51093345

Sure, that would be helpful.

It seems to be working for me (in both the real tour and the example), as long as I click 'add qualifier' rather than use the guider arrow to advance to that step.

I've deployed those changes, and I think it takes care of all those cases.

Thanks for identifying these problems!

I've just added Tulu (and a handful of other new-ish Wikipedia languages). You should be able to select it now.

This is really cool!

This is done, although it will require minor updates each time a new article quality model is added. Should be working now for both courses and campaigns for euwiki.

It's back up now, and appears to be working properly.

It's being migrated to a different server, as part of this: https://phabricator.wikimedia.org/phame/post/view/120/neutron_is_here/

@Tgr if a user does not already have an account, we send them the Special:CreateAccount with a return_to param to route them directly to OAuth. For example, like this: https://en.wikipedia.org/w/index.php?title=Special:CreateAccount&returnto=Special%3AOAuth%2Fauthorize&returntoquery=oauth_consumer_key%3D<some_token>%26oauth_token%3D<other_token>

@Ladsgroup we probably wouldn't hit the limit very often as long as the rate limiting is really only enforced for multiple simultaneous connections. The main process where the dashboard imports revision data for lots of revisions at a time has been rewritten with batching and no parallel connections at all (at least, for now).

@Theklan those unit abbreviations are now available for translation.