Copying over what I mentioned in my +2, TLDR, while the basic functionality is unbroken, there is still a fair bit of functionality that remains broken that will need fixing.

What are the "thumb steps" incantations exactly ?

cause/escalate edit wars.

More than this, there is a propensity to cause (to borrow a terminology used in the call, "a newbie biting machine") -- where multiple newbies get served the same erroneous suggestions, act on it, and then get reverted by increasingly irate experienced volunteers

Yep, no worries, just wanted to note something that I found confusing!

@LGoto In previous years, we've typically gotten a bit more leeway on the end time. It'll be nice to specify timezones or use zonestamp going forward (for what it's worth, I think it was technically 26th AoE when I submitted? :)

While I don't disagree with the direction, I'm a bit confused about the current patch being merged in its current :( Shouldn't we be i18n-ing that string ?

Based on the conversation on the page, I'm going to say that there isn't sufficient consensus at this time to implement this change.

Based on a talk with folks on Mod-Tools last week, not gonna go forward with the patch unless there is community interest (since properly implementing CommunityConfigurations will require some amount of rethinking of the deletion module as well)

For context, the normal contributor see this

To quote my comment on Discord:

I think a discussion on [[WT:NPR]] might be better/required? This is easy to implement technically, but I feel a bit iffy about whether we have consensus that NPPHOUR applies to UNBLARs?

Is there a way to get the more verbose state back, I can see the initial benefit of deprioritizing this data in the UI, but for example, having no way to see the full message here or track whether Patch-For-Review was added (which is prefereable in multi-patch tasks) is imo a net negative change in this context. (attaching how cut-off messages).

Gonna boldly remove this from good first task, I don't think I can identify a easy way of doing this without familiarizing myself with the gory internals of ResourceLoader and I don't think a new-to-code/Wikimedia person will have a much better experience.

What is the expected output in this context? This feels like expected behavior (kinda/sorta)

In T409165#11488827, @Escargot_rouge wrote:

The total of actually patrolled edits should be the total amount of edits which have been either patrolled or reverted, since edits that are cancelled are rarely marked as patrolled.

In T409165#11488610, @Ladsgroup wrote:

I'd argue since editor time is valuable, we should enable it so one editor doesn't need to review the same reviewed edit.

There was a patch and a task for this from Inductive a while back, lemme go fish it out.

@Jgiannelos are there any blockers on this? This affects a reader-facing component of Wikisource (the book download functionality), and having it broken for multiple weeks is less than ideal

Noting that, T366032 exists for me back when I requested access to logstash, not sure if that is sufficient

I mean, you are welcome to help out at the wiki-agnostic task, but it still stands, PageTriage has very limited usecases out of enwiki specifically. If we (say) 5years down the line fix all the wiki-agonstic issues and decide that PageTriage is usable across all mediawiki instances, this argument would make more sense. As it stands currently, it doesn't make sense to revert the commit for PageTriage (imo)

@DatGuy If this is critical infrastructure for the arbclerk team, I would suggest adding atleast one more (active) maintainer to increase the bus factor of folks who would be able to work on/maintain the tool

In T408915#11331410, @Jgiannelos wrote:

From what I understand parsoid is escaping <link> elements as expected. Those links are injected from Module:Header_template lua script to add schema.org semantics.
I think ideally the microdata shouldn't be injected as hidden links but instead being added in existing elements <div>/<span> elements.

@cscott I know you that y'all on the Parsoid team did a bunch of work on ProofreadPage and the <pages /> tag recently, this might be a regression that made it through ?

Yepp!

In T409668#11425061, @Reputation22 wrote:

for alert runbook, lets use this link for all alerts

https://commons.wikimedia.org/w/index.php?title=Commons%3AVideoCutTool%2FAlerts_Runbook#

i'll update this (maybe tomorrow or day after)

thanks

Sure!

@Yushu-kasai I assume jawiki is still interested in this being implemented?

Given that the code inside this extension can legitimately fit into a Phabricator comment, and to my understanding does not impact any major performance-sensitive components, I don't see why this couldn't/shouldn't be upstreamed into MediaWiki. For what it's worth, I think meta (and a few other projects) already monkey-patch this in using AbuseFilters.

In T12347#9912469, @Soda wrote:

I've started a draft for the documentation at https://www.mediawiki.org/wiki/User:Sohom_Datta/protection_indicators lmk if I should include anything else (for example, do we want to include the config flag/request process?).

This looks very nice, would it be okay to move it to the normal help namespace, as 'Help:Protection_indicators' or something? (Note that all content in the help namespace is under the CC0 license, so you should be the one to move it if you're okay with that.)

We could link to it from the Tech News message, instead of https://www.mediawiki.org/wiki/Help:Page_status_indicators.

The help page (for MediaWiki users) should also be cross-linked with https://www.mediawiki.org/wiki/Manual:$wgEnableProtectionIndicators (which is the manual for site owners).

@Samwilson I think the reproduction steps is to close the window and then reopen it and see if the loading animation shows up. (I'm also a bit rusty on what the bug is but I remember that it involved closing the window)

Only ones with external URLs! I tried the same flow with page content with no references, and it went through.

Based on the fact that VE shows a CAPTCHA in the same flow, I'm going to add ConfirmEdit (CAPTCHA extension) and the PSI team who I know was working on some CAPTCHA related work on ConfirmEdit recently!

Steps to reproduce:

• (Be an admin and have Parsoid views enabled in preferences)
• Navigate to the history of a page that has a revdeleted revision
• Click on the revision link of the deleted revision

• Once the next page opens up, click on the link "view this revision"

• You end up in the error screen

The URL in question is: https://en.wikipedia.org/w/index.php?oldid=1319024349&title=User:Sohom_Datta/sandbox&unhide=1. TLDR, I cannot view deleted revisions through that specific URL pattern unless I switch out of the new Parsoid parser mode.

@Reedy The stage is not coming from this codebase at all, mw.FormDataTransport, which is defined in resources/handlers/mw.ApiUploadFormDataHandler.js sends out the events based on the API response to the upload stash API (see mw.FormDataTransport.js:L383). The comment in the function says the following:

// Statuses that can be returned:
// * queued
// * publish
// * assembling

However, my assumption here is that the API has drifted from the comment since it was added. The only reference to 'fetching' in the mediawiki-core codebase is in UploadJobTrait::fetchFile which was added in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/982757 (for T295007). I don't see a good place where all the stages of a file upload are documented, except for this switchcase in SpecialUpload.php, but even then it does not appear to mention the "assembling" stage even though there are still references to the assembling stage in the mediawiki-core codebase in ApiUpload.php and AssembleUploadChunksJob.php. Maybe @Joe or @Ladsgroup who worked on the "fetching" patch have more insight on what the values of stage can be?

I would kick this back to the community to figure out what combination of templates to use. Implementing this into UploadWizard is the easy part tbh.

(Seems fine for me now)

In T405999#11239184, @EggRoll97 wrote:

In T405999#11236909, @Soda wrote:

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

I think the consensus was sufficient here. There was more than a full week before it was put into Phabricator, and multiple days after that before the change was deployed. The edit filter noticeboard has 351 people as watchers, and of those, 57 visited in the last 30 days, providing ample opportunity to leave any comments in opposition. It's not as if this was held in an obscure area, it's a noticeboard linked to in the noticeboard template, and yet still, there was not a single actual objection to this proposal.

What is Language Converter?

Still getting bunked out of accessing ACM publications

cc @hashar, who was the deployer

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

@Pintoch, I do think that makes sense.

Maybe this should be about surfacing the option in the UI on the wizard itself ?

Does this mean our JS code needs to use ESM as well ?

This should be doable in settings under Special:Preferences#mw-prefsection-uploads, right?

Also noting that if you end up in that kind of a situation, a reload (or even a retry with ?nocache=yes at the end of the URL) should submit a fresh try and fix it

@Chidgk1, This should be fixed now?

The setting is already set to default to false per https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/90892fa0af282cb9b774c306ac311512c4606ea3/wmf-config/InitialiseSettings.php#12932 so we probably just need to set enabled to true in the config.

In T376522#11199685, @Sdkb wrote:

On a technical level, I'm not sure I follow the concern about interaction with the campaign system.

@Matrix @Sdkb Would it be possible to revisit this? Adding an auto-patroller-only restriction seems like it will be a fair bit more work. (In particular, I'm wondering how this would interact with the campaign system?)

This was set by the specific Campaign that you were uploading under (see https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-at&action=edit). Vanilla UploadWizard does not have this functionality. Declining based on that.

Fixed in T347749

Adding the standards committee (who might be able to ask folks on the toolforge team to action this) (if @DaxServer is still interested)

(Error on my end)