Rob Lanphier wrote:
Hi everyone,
I'm in the process of figuring out a series of proposals that will help improve the usability of Pending Changes, in response to this: http://en.wikipedia.org/wiki/User_talk:Jimbo_Wales#A_way_to_resolve_the_ling...
One complaint that many people have with Pending Changes is that bad-edit/reversions end up cluttering the page history. An example of that is here: http://en.wikipedia.org/w/index.php?title=The_Beatles&offset=20100830000...
That leads to long stretches of history where nothing actually changes: http://en.wikipedia.org/w/index.php?title=The_Beatles&action=historysubm... (note: no diff and "12 intermediate revisions not shown")
This isn't exclusive to articles under Pending Changes, just more pronounced when PC is on a high traffic article.
Many of the edits are marked as "good faith", so deleting or hiding them from most users wouldn't be a good idea.
Note that the two revisions in the diff example above (diff=378780503&oldid=378261233) are identical, which could be easily verified with an MD5 checksum of the text.
One general improvement we could make the history is to optionally collapse long stretches of reversions. So, in the case of The Beatles article above, instead of seeing this:
....
The text "4 revisions not shown" would be a hyperlink that would expose the collapsed revisions. The revisions would still be available for everyone to view; they just wouldn't be given the same level of visibility as revisions that had a more lasting effect on the current article.
I've drafted this up here: http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Reversion_collaps...
Let me know what you think.
Thanks Rob
I like it, but I would begin by making it as expanded, then allowing to hide on a click. It's tricky since you (usually) want the oldest revision with the same content. Having the content initially collapsed would also allow you to hide on different levels (expand a revert which went to last week but hide reverts this day...).
MZMcBride wrote:
Would this require storing the checksums in the database or would this be done dynamically on page history views? There's a related bug about implementing checksums of page text into MediaWiki. Some people aren't thrilled with the idea.[1]
If this is added to revision table, it should be done at the same time as adding the character count. The population script would then only fetch (and ungzip) the texts once.
I wonder if there is some shorter hash that would perform well for this. Even with the restricted set of characters we use, things like crc32 have too many collisions.