Page MenuHomePhabricator

Diffs are tagged as "Edit Check (references) activated" while users haven't added any footnote
Closed, ResolvedPublic

Event Timeline

Trizek-WMF renamed this task from Diffs are tagged as Edit Check (references) activated while users haven't added any footnote to Diffs are tagged as "Edit Check (references) activated" while users haven't added any footnote.

I investigated the desktop ones. 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.

This is deliberate behavior for the tag -- editcheck-references-activated is supposed to track "the user saw edit check at some point before they saved", and you can get an identical tag arrangement by writing an edit that triggers edit check, backing out of the check, altering your in-progress edit so that it would no longer trigger the check, then saving (this is even a valid thing to do, if you e.g. don't agree with our choice of placement for the citation and want to put it in the middle of the content you added). That said, it's sort of confusing because it can make it look like edit check activated on specific edits that it would have no business activating on.

The mobile ones look a little different, so I will dig a bit deeper there.

Thank you for investigating, David.
Yes, it is quite confusing. Shouldn't it be repurposed as a maintenance tag?

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

David, I agree with you in thinking that it's useful to be able to see the range of edits people make during edit sessions when the Reference Check is shown even when the changes people end up publishing in isolation should not have caused the Reference Check to become activated. [i]

With the above said, Benoît + David, I agree with both of you in thinking that absent any intervention, we'll risk more people (our future selves included) to become confused if/when they encounter edits like:

I've filed T373949 for the work of deciding how/if we might evolve the Edit Check tags to avoid the confusion described above.


i. E.g. maybe someone decides to "back out" of the Reference Check workflow and remove the new content they were seeking to add.

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.

Now, @DLynch, can you please say more about the above? How does someone declining the Reference Check in a previous session impact what tags are appended in a subsequent edit session?

@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.

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.)

I've filed T373949 for the work of deciding how/if we might evolve the Edit Check tags to avoid the confusion described above.

Thank you. It is really important to clarify this, as confusion could be a blocker. Communities look for accurate information.

@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.

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.)

Understood. Let's do this then:

  1. Revisit the question of revising how flags behave within the context of the broader thinking we need to do about how tags behave to support the Multi-Check experience.
    • To hold us accountable to doing this, I've added a new open question ("3.") to T342460's task description which reads: "What – if any – adjustment(s) will we make to how Edit Check-related tags are flagged to ensure Edit Check tags don't "bleed" between discrete edits/edit sessions?"
  2. Use this ticket to continue investigating the mobile-specific issues, as David mentioned in T373690#10106713.

I followed up on T375449 since it's more-specifically about this.

ppelberg claimed this task.