Page MenuHomePhabricator

[SPIKE] Add edit tags for each type of media for Hashtags tool
Closed, DeclinedPublic

Description

In the parent task, a couple of edit tags were added to facilitate tracking of additions and removals of media of any type in an edit.

The Hashtags tool has recently acquired a similar feature to support media-related campaigns like #WPWP. In this case, however, campaign organizers would like to distinguish between different types of media being added, so they can perform queries like "look up all edits with hashtag #WPWP that add an image." The Hashtags implementation essentially watches the recentchange EventStream and, at each change, fetches and compares the types of all media in an article before and after the change.

It would be great if the tool could be ported to use the new tags instead of this custom logic. For that to happen, we probably need at least two things:

  1. There should be different tags for each media type (e.g. mw-add-image, mw-add-video, mw-add-audio).
  2. Ideally, the tags should also be added to the recentchange stream for ease of consumption. I'm mentioning this for completeness but it should probably be its own separate task.

Would it make sense to add these new tags?

Event Timeline

Current media change edit tags use caches of previous/new revisions to figure out whether there are media changes (and which files they are)
Those do not, however, contain additional information about the files.
Unless somehow in the process that information is already available and in some cache (which might be the case!), it might be a pretty expensive thing to look up.
Let's make this a spike to figure out how we'd know about the file type and re-assess?

matthiasmullie renamed this task from Add edit tags for each type of media for Hashtags tool to [SPIKE] Add edit tags for each type of media for Hashtags tool.Jun 30 2021, 4:56 PM

We ended up abandoning our original pursuit of trying to add more generic edit tags.
There were significant technical challenges (it's an intensive to parse 2 revisions to compare them) and it proved hard to nail down exactly what we even wanted to track (what to do with media in templates? do we include icons? how? etc.)
This more specific task would have all the same challenges and even more problems (e.g. even more intensive to figure out what type of media it was) than the one we've given up on, so I don't see this happen anytime soon, or ever. Like the other task, there may be alternative, better solutions to accomplish what is desired.

Declining as per @matthiasmullie's comment above.