Trending should track reverts
Closed, ResolvedPublic
Actions

Description

The trending processor should be able to record how many reverts that page has experienced to get a sense of edit conflicts.
Unfortunately there is no clear way to detect this so we may need to resort to inspecting the comment field of an edit.

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Track reverts as best as possible	mediawiki/services/trending-edits	master	+43 -0

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Declined	None	T140102 [EPIC] As a user, I want to see see a list of currently trending articles
Resolved	Jdlrobson	T145553 Subscription: Trending service should be able to subscribe to edits in real time
Resolved	Jdlrobson	T145571 Recovery: Trending service should be able to replay last 1hr of edits
Resolved	phuedx	T145554 Process: Trending service should process real time edits
Resolved	Jdlrobson	T152421 Trending should track reverts

Event Timeline

Jdlrobson created this task.Dec 5 2016, 4:56 PM

Maybe this has already been discussed (I feel like it has), but does MediaWiki know when a revision is a revert? If it does, perhaps we can add this as a boolean field on the revision-create event.

I don't think MediaWiki does mark revisions when they are reverts... but I feel like it probably should.... I haven't worked out who best to talk about that with. Maybe the editing team and @Jdforrester-WMF ?

You mean, when the two revisions have the same hash? Perhaps our use of ExternalStorage can spot those?

It'd be nice to know when the revision comes into MediaWiki from the POST, if it was a revert. Even if we don't actually store this fact in the revision table in the db (although, that would be pretty nice!), the MediaWiki Revision class could have an isRevert() function. This wouldn't capture manual reverts, where someone actually copy/pastes the previous revision text, but I assume that's an edge case. Knowing if the revert revision UI was used to create the new revert revision would be good enough. Hm, I guess it would also be nice to know which revision id's content was the source of the new revert revision, but I doubt Jon needs that, and we can infer that decently well from the hash.

^ took the words out of mouth @Ottomata ! That would be extremely useful and yes I don't think we need to consider the edge case of manual reverts. Method could be called isAutomaticRevert if that's a problem. @Jdforrester-WMF is that something that editing is thinking about?

In T152421#2847722, @Ottomata wrote:

It'd be nice to know when the revision comes into MediaWiki from the POST, if it was a revert. Even if we don't actually store this fact in the revision table in the db (although, that would be pretty nice!), the MediaWiki Revision class could have an isRevert() function. This wouldn't capture manual reverts, where someone actually copy/pastes the previous revision text, but I assume that's an edge case. Knowing if the revert revision UI was used to create the new revert revision would be good enough. Hm, I guess it would also be nice to know which revision id's content was the source of the new revert revision, but I doubt Jon needs that, and we can infer that decently well from the hash.

There are three different user paths (off the top of my head) that create a 'revert' (undo, rollback, and nuke), plus the manual route (which for certain wikis which use a bot to revert are probably the main ones).

In T152421#2847844, @Jdlrobson wrote:

^ took the words out of mouth @Ottomata ! That would be extremely useful and yes I don't think we need to consider the edge case of manual reverts. Method could be called isAutomaticRevert if that's a problem. @Jdforrester-WMF is that something that editing is thinking about?

No. I fear it's a bit more complicated that it sounds at first blush.