The clarification you shared in T371769#10135854 very much helps...thank you, @Urbanecm_WMF.

Per T370989#10144289 and discussion in Slack, removing this from the Editing Team's planning board for now.

In T374572#10139394, @DLynch wrote:

Glancing at WMDE's patch that added this instrumentation, it doesn't quite work how it's documented on the VEFU page. Specifically, automatic-generate-fail-searchResults and automatic-generate-fail-network won't be logged under the "citoid" feature, but rather under the "CitoidInspector" feature. Depending on exactly how the queries were being run in T368988, that'd probably be enough to make it not show up in the analytics.

Said patch did also add the automatic-generate-fail action, which would be logged under citoid, and should theoretically just be the overall sum of those other two. So depending on what you were relying on to detect failure, the results might not even be impacted.

In T323169#10139545, @WhatamIdoing wrote:

It's broken again. Edits like this can only be done manually.

Great spot...thank you for stopping by to make us aware, @WhatamIdoing!

Thank you for pulling this all together, @MNeisler.

Per what @MNeisler and I talked about offline today, we're going to move forward with the approach she described in T371158#10134639 above.

Meta: per offline discussion with @nayoub, we're going to revisit this ticket once we're through with T349027.

In T371769#10043631, @ppelberg wrote:

It sounds like to avoid the issue captured in this ticket, the Editing Team needs to ensure:

1. Any manual instructions we offer people manually migrating active Flow pages to sub-pages/archives mention ____
2. The migration script we will be writing, and are investigating in T371738, will need to ____

Martin: can you please fill in the two blanks (____) in "1)" and "2)" above? Of course, if there is anything about the two points above that you think should be modified, I'd value knowing as much.

@Urbanecm_WMF, gently nudging this to ask: could you please help us fill in the blanks within "2." above?

Next steps
@nayoub to...

1. Share link to Figma file where components are being iterated upon
2. Upload images of the latest state of all components
3. [if time] upload images from "2." to Commons

Update
@MNeisler and I are using the findings from T371726#10113802, T370726#10096610, and T371737#10100308 to propose an improvement target, the rationale for which we're drafting here: KR Proposal/WE 1.2 FY 24-25

In T368438#10095733, @Trizek-WMF wrote:

We already tag these edits in Recent Changes or in Watchlist, and Special:Log already lists all tags. Adding these tags to Special:Log should just be the continuation of this work. #editcheck-link and #editcheck-reference-reliability should be added to RCs and Watch lists too.

@Trizek-WMF: can you please share what you're seeing that's leading you to think #editcheck-link and #editcheck-reference-reliability already exist?

In T373690#10115577, @DLynch wrote:

@ppelberg It's because when you edit a page in VE and save it, it doesn't cause an actual page-reload -- instead, the new content is just dropped into the existing page. Thus anything which is set "permanently" within a single pageview will still be set, and if the user decides to immediately edit the page again it'll still be there.

Ah, okay. I see. Thank you for explaining this, David.

In T373949#10117937, @Trizek-WMF wrote:

Should we use this task to think about how Multi-check will handle multiple tagging?

Mmm, needing to converge on how the existing tagging approach will need to evolve to handle the complexities @DLynch described...great spot, @Trizek-WMF.

In T373690#10115577, @DLynch wrote:

We absolutely could reset this flag when you exit VE, if that was the preferred behavior. (We could even reset it when you back out of the save process, though I think it'd become kind of meaningless then.)

In T373949#10115587, @DLynch wrote:

It might be less-overloaded to say "browser pageview" rather than "edit session". The latter sort of overlaps with some analytics terminology, and might imply that the tag is sticky if you move to a different article and start editing, which it is not.

Good spot, David. Updated.

They all seem to be because we never clear the "edit check was activated" flag in a given pageload, and those edits were made immediately after a previous edit that did have a decline-reason given.

Thank you for filing this, @Trizek-WMF and +1, thank you for investigating, @DLynch.

In T373079#10107098, @Msz2001 wrote:

Given that the patch has been reviewed, I'll go on with backporting it on Monday, 2 September.

Wonderful and sounds great! Thank you, @Msz2001 ^ _ ^

In T373079#10106001, @Msz2001 wrote:

In T373079#10089090, @ppelberg wrote:

Wonderful. Next Tuesday it is, Tufor!

I'll ping you here should that date need to change for any reason.

Hi! What's the status of this? I know this is not urgent and a few days of change will not ruin anything, but I wanted it not to become buried for eternity.

Due to some people being out of office, this got delayed. As a result, I think this will now need to happen this upcoming Tuesday, 3 Sep.

Language for Tech/News

"What do you should be logged when someone attempts to link to and/or reference a blocked domain ''within'' an edit session?"Please review [[phab:T368438|T368438]] and share what you think."

Next step(s)

1. @dchan to verify state of backend updates to ensure necessary information is being passed to front-end to display error message.

Thank you for sharing the state of this work, @zoe.

Steps:

1. Visit: v

We shared the proof of concept on 5 June 2024: https://www.mediawiki.org/wiki/Edit_check#5_June_2024

This is done. As of 28 June 2024 [i], Permalinks are available at all wikis by default.

In T369235#9952164, @ppelberg wrote:

Assigning this to me to articulate what we converged on as a team during today's team meeting.

For my future self: default to treating Checks as discrete/atomic in service of: 1) simplifying implementation complexity, 2) keeping Checks lightweight, and 3) creating space for us to arrive at a point of view of how Checks ought to be prioritized and presented in relation to one another.

In short, to start we're NOT going to combine related Checks into a single workflow. If/when we come to think the impact of doing so is worthwhile, we'll revisit this decision.