Page MenuHomePhabricator

Clarify the meaning of the editcheck-references-activated tag
Open, Needs TriagePublic

Description

This task involves the work of deciding how we'll evolve the set of Edit Check tags to help us (volunteers and staff):

  1. See the full range of edits people publish in edit sessions where the Reference Check is shown
  2. Detect false positives. Read: identify edits where the Reference Check was shown when it does not make sense for it to have been.

Story

Background

editcheck-references-activated is implemented in such a way that the tag is appended to all published edits if, at any point, during said browser pageview the Reference Check was shown.

This approach is helpful in so far as it enables us to see the full range of edits people publish in response to seeing the Reference Check...even when the edits people end up publishing should not have caused the Reference Check to become activated in the first place.

This approach can also be confusing in so far as it can be difficult to differentiate between the following two cases:

  1. The Reference Check was shown when it shouldn't have been
  2. The Reference Check was shown as expected and in response, someone revised their edit in a way that makes it look like the Reference Check was shown in error

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

Event Timeline

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.

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.

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

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

Yeah, we very likely need to do a major adjustment to how this tagging works for that. Even before we have multiple *types* of check, having multiple instances of the same check will make this confusing enough.

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.

I'm thinking we use T342460 for converging on that broader approach and using this ticket to as an input to it.

I'm thinking we use T342460 for converging on that broader approach and using this ticket to as an input to it.

This task has a focus on databases. We need to think about tags in matters of how each history line will display that information. The more checks we will have the more crowded history pages will be.