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_lin…
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=2010083000…
That leads to long stretches of history where nothing actually changes:
http://en.wikipedia.org/w/index.php?title=The_Beatles&action=historysub…
(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_collap…
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.