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.

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.

@Xaosflux - That's an understandable concern. We discussed it a bit and feel like changing it to "copied text" (or something similar) would unfortunately be confusing. Often when people talk about "copied text" problems on Wikipedia they're talking about copy-paste moves or similar problems, while text plagiarized from outside sources is most often referred to as "copyvio" or "copyright violations" (e.g. the Copyright violations policy, the Copyvio-revdel template, etc.). I don't think there is much legal risk from flagging something as a "potential copyright violation" in good faith. Even outright incorrectly calling something a "copyright violation", if done in good faith, is legally OK in the US at least (IANAL). We're going to go ahead with the copyright violation wording, as we think it is the easiest to understand, but we'll be looking out for further feedback from the community on it. Hope that sounds reasonable.

Or "Potential" or "Suspected" or something. Not sure what exact verbiage is best :P

@Xaosflux - In most contexts it says "Potential issues: Copyvio" or "Potential copyright violation", but it looks like the Log page title should be changed, as it says "Copyvio event log". It should be changed to something like "Possible copyright violation log", otherwise people are going to be upset. Pinging @MMiller_WMF and @kostajh.

The original reason that Thanks were not allowed for bots is simply that it didn't seem like it made much sense. Humans don't often log into bot accounts (with the exception of some AWB users), and bots themselves aren't capable of appreciating thanks. We thought it would just be annoying to bot owners when they logged into the bot account and were suddenly hit with 100+ thanks notifications. But on the other hand, maybe that would actually be a nice experience, I dunno. Can you explain why you think it would be a good idea to allow thanks for bots (other than resolving the inconsistency)?

I replied to the inquiry on meta. I think we're good to move ahead.

if ( $revision->getVisibility() !== 0 ) {
    // skip row.
}

Yeah, that looks right to me.

Ug, that documentation page is actually terrible. (It's basically just a bunch of 10 year-old discussions.) See https://www.mediawiki.org/wiki/Manual:Revision_table#rev_deleted instead.

@kostajh - We probably want to skip cases where the revision in question has already been "deleted" (which really means hidden) as the reviewer won't be able to see the revision in question (unless they are an admin). This can be checked with the rev_deleted field. See https://www.mediawiki.org/wiki/Bitfields_for_rev_deleted. I agree with the assumption that we should not create log entries for this script run if possible.

@GeoffreyT2000 - Well, it's clear that RfC isn't going to result in consensus to change, so feel free to close it as [[WP:SNOW]]. Thanks for the effort though.

It looks like we still haven't informed the Pashto Wikivoyage (ps.wikivoyage.org).

@Keegan - What happened with Pashto wikivoyage? No one to translate?

@Insertcleverphrasehere, @Compassionate727, @GeoffreyT2000 - The way that English Wikipedia handles this situation seems overly complicated. Ideally we want every action that PageTriage takes to be configurable on-wiki (See https://www.mediawiki.org/wiki/Extension:PageTriage#On-wiki_configuration). Setting up support for creating additional pages and adding disambiguation strings would likely necessitate breaking the config model and resorting to custom code for English Wikipedia. The more we write custom code for English Wikipedia, the less configurable PageTriage becomes and the less likely that it will ever become available for other language wikis. Is there any possibility that English Wikipedia would be willing to simplify the AfD process and just list new nominations on the same page? This would also have the advantage of allowing people to easily refer to previous debates and would also simplify the nomination process (which right now is kind of a pain when there are previous nominations). I know this would be a big change, but I really don't understand why the current process is so complicated.

Approved.

I can reproduce in Safari or Chrome, logged in or logged out, on MacOS. I'm hovering by hovering the cursor on a laptop (not touch-screen). Bug appears regardless of whether the pop-up is above or below the cursor. Only happens for certain links though. Window size doesn't seem to affect it.

@MaxSem - Do we know how either of the existing tools would handle the example you provide? Would they just ignore the tspans or what?

@Niharika - Clearly, MediaWiki needs a new user right to properly support English Wikipedia's article creation restrictions. Since CommTech built ArticleCreationWorkflow it seems logical for them to work on it. I don't think it would take a huge amount of work, but it would require some careful changes in core.

@Aklapper - Somehow this task is in 2 different columns on the same board simultaneously. I can't find any mechanism to remove a task from a column, but not a workboard. Any advice?

Problem is that the number of affected pages was somewhere > 500,000

Do we know how many pages are still affected? Where did the 500,000 figure come from?

Approved.

So according to Google's AI wisdom, the word "firefly" is a TV show, and you have to explicitly tell it that you actually mean the insect instead. We are all doomed.

@Imarlier - Have y'all tried the "Request Indexing" feature in Google Search Console for the specific URLs that are affected? i.e. in Google Search Console, go to "URL inspection", enter the URL of the page that has the bogus search results, hit return, and click on "Request Indexing" next to where it says "Page changed?". That should force Google to recrawl the page and reindex it with the current content. My apologies if y'all have already tried this. (I didn't read though the incredibly long discussion above.)

The only update that should be needed is replacing John McCain with Jon Kyl.

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

That sounds like a different (but legit) bug.

@zeljkofilipin - Is that example helpful?

I would still agree that they are a privacy concern if they were third party, but as discussed above, they are not.

Got it. Even though they're not "3rd party" I still think we should remove them unless they are strictly necessary so that there's no confusion or uncertainty about it (especially with the community).

Should the interface load from the server and be enhanced with JS
Not a must, but may give us flexibility with no-js support as well as speed

I don't think there's much point in trying to make sure it works without JavaScript. The live SVG preview interface (which I would favor) will require JavaScript to manipulate the SVG (otherwise we have to do a round-trip for every edit and have the client reload the whole image).

It's also loading a tracking pixel from WordPress: https://pixel.wp.com/g.gif (which for some reason doesn't show up in Aklapper's output above.

Bulk account creation tool: No matter how attractive we make advanced registration, there will always be drop-ins attendees on the day of. To help Event Creators move more quickly, we could make a tool that would let them register multiple participants at one time.

@jmatazzoni - Looks like this might already exist: https://accounts.wmflabs.org/acc.php

@MMiller_WMF - Here's the spike. Feel free to pull it into the current sprint if needed.

My most recent tests from home and the WMF office have shown no issues. In both cases, the United States article loads in about 10 seconds. @Esanders - Do we have any metrics on how often the "Error loading data from server" message is displayed in VE? I'm guessing not, but just thought I'd ask.

@Jdlrobson - You can still use mustache/hogan with webpack. https://www.npmjs.com/package/mustache-loader.

6 months and 5 people, for 1 story point :)

@Samwilson: ^ (In case you want to want to fix the variables passed by reference.)

Now that we have aliases, any chance we could implement an "articlequality" alias for wp10, hopefully before it is baked into the JADE extension. Otherwise, "wp10" is going to start being surfaced in the MediaWiki user interface which is sure to cause confusion.

@Hsarrazin: Typically on other wikis, the way to notify a project of a discussion is to post on the project's talk page.

Yes, the settings related to $wgGroupPermissions in your LocalSettings.php, especially any related to the bot user right or user group. I don't imagine this is related to the bug, but it's good to eliminate that variable since you mentioned it.

@Tenbergen: Can you paste your user group config for your wiki here so that we can try to reproduce?

I really don't think Echo Notifications are the right solution to this problem. If you need to message more than 50 people at once, you should probably use a mailing list. There's also the Newsletter extension, which is installed on Mediawiki.org and could be installed on Wikidata as well. If neither of those solutions will work, I think we may need to create some new software specifically to address this use case (that is separate from mention notifications). The fact that {{ping project}} uses hidden content is also problematic. Rather than expanding this hack, maybe we need something different.

Please don't call it "Review"! There are already too many things on Wikipedia called review: the page reviewing process associated with https://en.wikipedia.org/wiki/Wikipedia:New_pages_patrol, the draft reviewing process associated with https://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation, reviewing pending changes, and page patrolling (which is related to page reviewing and sometimes called the same thing). It is already extremely confusing to figure out what someone means when they say "review" on Wikipedia. "Tag" has the same problem. And I agree with Mooeypoo that "Judgement" has negative connotations.

@Steinsplitter, @eranroz, @Geagea - I believe CommunityTech decided against implementing that feature (posting to a centralized page) since SteinsplitterBot was already doing it. In cases where a community-maintained tool is already doing something, CommTech almost always prefers extending that tool rather than taking over the functionality, so +1 for having SteinsplitterBot handle that part.

Doing it in a text editor is painstaking. I heartily agree that the tool should allow users to do small scale style changes.

Just be aware that implementing that will be a lot of work with lots of edge cases.

My understanding of the thumbnailing process, which is limited, is that it doesn't involve ResourceLoader. The parser and probably some other pieces translate the [[File:abc.svg|lang=de]] in the local WikiText into an HTML image tag for a specific PNG thumbnail, for example, https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/abc.svg/langde-250px-abc.svg.png. If that thumbnail doesn't yet exist, the librsvg script on the scaling servers generates it with the requested language (if any was requested) at the desired resolution.

@Tgr - Thanks for the info. Fixed it in the template: https://en.wikipedia.org/w/index.php?title=Template:Infobox_writer&diff=prev&oldid=855362428.

BTW, I noticed that some of the old bogus accounts like "Kaldari" (uppercase) and "kaldari2" are now gone (or merged?). Would it be possible to delete or merge my temporary account I made to work around the bug (which also uses rkaldari@wikimedia.org)? No rush, just wanted to ask in case it's easy now. Thanks!

@mmodell: OMG, it works! I can log into my old account and all the history is still there too! Thank you! Thank you!

@Reedy - Any update? Did you want to do a walkthrough with the developer for this one or just look at the code?

@Esanders: I tried benchmarking this again, but got some weird results. On the article United States, the first two times I tried to load it with NWE, I got a timeout error from the editor after 60 seconds: "Error loading data from server". After that, however, loading was smooth and fast: typically about 10 seconds or less. Any idea what may have caused the delays initially? Maybe a missing server-side cache? (It's also possible this was just an issue on my end with my internet connection.)

Regarding things like repositioning text-boxes, changing text size, combining text boxes, etc. my personal opinion is that that sort of work should be done in Inkscape (or other SVG editors), not a translation tool. Modifying positioning data in SVGs can actually be very complicated due to grouped objects, different methods of scaling, etc. It's not like a PNG where you only have to move pixels around. This tool should be for doing one thing and doing it well: translations (especially since everyone on the internet has access to Inkscape for all the other SVG editing tasks). Also, keeping the feature-list short means less maintenance and things to break.