@Steinsplitter - Ah, I see. While extended-reviewers can technically review image licenses now, I think they can be trusted not to violate the review policy (or hack UploadWizard to do a false review). We don't have to enforce every policy with an AbuseFilter, especially for trusted users, in my opinion. I'm open to hearing other opinions though.

I'm happy to provide the manager approval, but you'll still need a C-level sign-off.

I fixed the AbuseFilter, so this should no longer be an issue. Extended-uploaders are trusted regarding licensing, so I just exempted them from the filter. Agree that moving the check to the server-side is the best long-term solution, but that's covered in T89131.

@Steinsplitter - I fixed the AbuseFilter filter. You forgot to exempt the extended-uploader user group when you added the {{FlickrVerifiedByUploadWizard.*}} template. To be added to the extended-uploader user group, you have to be vetted for knowledge of the licensing policies, and be trusted to import files from Flickr that aren't Flickrwashed, so those users should be exempted from the AbuseFilter.

@Esanders - It looks like the display:inline-block change caused a different bug, specifically, you can no longer have heiro elements inline in text (T210695). Could you take a look (or revert)?

FYI, the 90 days comes from $wgPageTriageMaxAge.

Could someone write a description for this task? What is the goal here?

@Volker_E - Here's what it looks like without the Horizontal Layout and having both buttons...

Community discussion of the bug here.

Yes please! I've likely received over 100 of these notifications, and every time I do I feel like I've wasted 2 seconds of my life. Granted, that only amount to 200 wasted seconds, but still!

@Gryllida - As Aklapper alluded to, you can thank an admin for deleting a page from the deletion log: https://en.wikipedia.org/wiki/Special:Log?type=delete&user=&page=&wpdate=&tagfilter=

@jmatazzoni - Both of those designs look fine to me. Any preference?

@Volker_E - Any preference on how to fix this?

@matmarex - For now, it's fine if this only works in VisualEditor. Thanks for your quick work on this!

Fix seems to work. Been testing for the last few days and haven't had any cases of not getting the toolbar.

FYI, this has been made into a proposal at the 2019 Community Wishlist.

@Prtksxna - As far as design, I guess we need to figure out if this is a button or a link or what. It doesn't need to be very prominent as I expect it will rarely be used.

@Prtksxna, @Niharika - I'm fine with not having a special page so long as we have some kind of text accompanying the link or button that links off to a help page explaining the data and how to request additional data. So something like "For additional information, see [Help:Downloading user data]." The default message should link off to a help page on MediaWiki.org, although we'll probably want to override this (via WIkimediaMessages extension) to point to a more WMF-customized version on meta.

Yes, the Architecture Committee decided against making users' IP addresses available. You can read through T387 for the gory details. It could perhaps be revisited, but that was the last decision on the matter.

@jmatazzoni - That proposal was rejected by the Architecture Committee (see T387). Otherwise, we could have just deployed the AccountInfo extension.

I tweaked the description to focus on the account data download, since that's all we're doing right now.

Setting to low priority after discussing with legal. The main priority is to provide "personal data", i.e. data about their account rather than content created by their account.

Yeah, just that one for now, AFAIK.

According to the documentation, "This is a status for parameters which should not be used any more." So the best thing to do would be to have VE filter them out, IMO.

@matmarex - For this project, support would only need to be added to VisualEditor. Just to clarify, is it currently possible to create a specific tag that anyone (even anonymous editors) can add (via the API)? I assume so, but would like to double-check.

Still haven't figured out when the original interface was switched to oojs-ui though, which was the more significant UI change.

Haven't narrowed it down completely, but I suspect it may have been https://github.com/wikimedia/oojs-ui/commit/11d868b39f83a79fe6aeefec8c774ae534ff9c95.

It looks like the grid layout aspect was lost due to upgrading from oojs-ui v0.23.0 to v0.23.1.

@Etonkovidova, @SBisson - Looks like its still broken for some reason.

@jmatazzoni, @Mooeypoo - If this task ends up being complicated, for example, if it requires setting up a storage solution, let me know and we will reconsider whether or not it is necessary. From my conversations with Moriel, it sounds like the user data export should be straightforward, but this one may be complicated due to edge cases.

@aezell, @jmatazzoni - We need it to be machine-readable, not human-readable.

We probably won't be able to use CSV for the User Data, since it's not just a key-value list, but a collection of complicated data. For example, the user group list, wiki list, and preferences will be arrays rather than single values. In order to make that data properly machine-readable it will need to be in a JSON or XML file (to handle the different types of data). The User Contributions, however, could probably work as a CSV or JSON.

We should switch the AbuseFilter to be tag-only and make sure the new patch is working correctly. I tried to create a new tag for it, disallowed page creation, but for some reason it won't let me add it. Maybe @MusikAnimal could help.

Note that partial blocks are only currently enabled on Test Wikipedia.

Awesome job, @RHo! I think you did a great analysis on these. One point I would like to add about ArticleFeedbackTool:

Looks good to me.

@Johan - Perfect! Thank you.

Sounds good to me as long as it doesn't screw up the floating toolbars.

Ah thanks! I hope y'all aren't planning on changing it again soon :)

@Carlb - In most cases those links were migrated to the RelatedWikipedia template (or RelatedCommonsCat template). However, in the case of that page in particular, there is already a link to Wikipedia:Civility in the See also section, so using the RelatedWikipedia template would have been somewhat redundant. Alternately, you could create an interwiki link to Wikipedia:Civility in Wikidata if the two pages are roughly equivalent (which would add it to the sidebar). We've tried to migrate as many pages as possible without loosing links (especially in the main namespace), but the process isn't perfect. The links in the User, Wikivoyage, and Template namespaces were mostly just removed since these were considered less critical. Let us know if there are other pages we should re-visit, and sorry if the process hasn't been ideal.

@Catrope - I knew you were going to say that ;)

The way to fix this is a bit tricky. The entire pop-up dialog is being displayed (albeit half off-screen), so technically you can't just make the dialog scrollable (as there's nothing to scroll to). The proper way to fix this is probably to detect if part of the dialog is off-screen at the time it opens (see https://stackoverflow.com/questions/8897289/how-to-check-if-an-element-is-off-screen), and if so, reduce the height of the dialog so that it just exactly fits on the screen and change it to overflow: auto (so that it gets scrollbars).

@Bencemac - TemplateWizard is for the old WikiText editor, not VisualEditor. VisualEditor has it's own interface for adding templates.

Thanks @Samwilson. Nice work on this @MaxSem.

Should probably be mentioned in the Tech News.

Got it. In that case, please document at https://www.mediawiki.org/wiki/Extension:ArticleCreationWorkflow, or wherever is appropriate.

@MaxSem - Now that this has been merged, please add documentation at https://www.mediawiki.org/wiki/Manual:User_rights#List_of_permissions (and anywhere else it is needed). Seems like this probably also warrants a mention in the ReleaseNotes if that hasn't been done already. Thanks.

FWIW, the config documentation says that we need to get either @greg or @Jdforrester-WMF to approve adding this to the whitelist. I've added both of them as reviewers for the config change patch. Greg suggested we add TemplateWizard to https://www.mediawiki.org/wiki/Beta_Features/New_Features, although no one has used that page for last two years. My suggestion is to ping James when he gets back from the RI offsite on Monday and see if he'll just +1 the config change, and then schedule it for a SWAT deployment next week. (Note that I will be on vacation that week.)

It looks like the new Beta Feature code is on Test Wikipedia now, but TemplateWizard isn't showing up in the Beta Features there. It probably needs to be added to that weird Beta Features whitelist in the configs.

You might as well give kosta restricted. He's starting deployment training and will probably be requesting deployment by the end of the year. In other words, whatever group you assign him to is only going to be temporary anyway.

There are many situations in which it is inappropriate to mark a page as patrolled when you are tagging it.

@TheDragonFire - Can you elaborate on that? When we were originally developing the Page Curation tools we were asked to make tagging automatically mark the article as reviewed (to save the reviewers a step). In what situations would a reviewer tag an article, but not want to mark it as reviewed?

It is still common for a user to not be able to determine if they have already sent a "thanks" or not.

Yeah, that sounds like a different problem. FWIW, the main reason it was built how it was (using the session) was to keep it lightweight and performant. I'm not convinced that this is enough of a problem to add extra database queries to all our revision interfaces to make sure people know every revision they've ever thanked.

I can't reproduce this bug currently. Can anyone provide reproduction steps?

Looks like reporting on enwiki is working now: https://en.wikipedia.org/wiki/Special:Log?type=pagetriage-copyvio

This would be great as an unconference talk on Friday, and maybe a lightning talk preview as well.

@Marostegui - I've heard from multiple people about unexpected fires delaying Ops/DBA work, but no additional information. Is there a phab ticket we can follow for these fires? These schema changes have been delayed multiple times, so obviously we want to push them along as quickly as possible, but it would probably work better if we can poke you when we know the current fires are out.

@kostajh @SBisson - Looks like we forgot about this. It's an easy config change though.

@aaron - Any thoughts about the course of action suggested above in T206580#4655234?

I would love to. Is there someone we can assign this to? I've been meaning to do it myself but I have other things on my plate.

Unfortunately, all the QA Engineers are already stretched pretty thin and (as you know) CommTech doesn't have any dedicated QA resources. But I was thinking maybe you could get Sati to help QA (and/or another developer).

@Niharika - Did you want to assign someone to QA this?

@fgiunchedi - Are you still working on this or should it be unassigned? It looks like this is blocking T36947 (i.e. upgrading librsvg to fix SVG rendering problems), which I need fixed for T201207.