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:
(cur | prev) 14:37, 16 August 2010 Mclay1 (talk | contribs) m (135,528 bytes) (→External links) (undo) (cur | prev) 17:55, 14 August 2010 Yousou (talk | contribs) (135,560 bytes) (Undid revision 378906775 by 75.28.163.61 (talk)) (undo) (cur | prev) 17:52, 14 August 2010 75.28.163.61 (talk) (135,899 bytes) (→Events leading up to final tour) (undo) (cur | prev) 04:15, 14 August 2010 Nofoolz (talk | contribs) (135,560 bytes) (undo) (cur | prev) 04:09, 14 August 2010 174.115.162.100 (talk) (135,582 bytes) (undo) (cur | prev) 04:07, 14 August 2010 125.60.248.136 (talk) (135,560 bytes) (→Events leading up to final tour) (undo) (cur | prev) 21:49, 13 August 2010 Rodhullandemu (talk | contribs) m (135,537 bytes) (Reverted edits by Foofinshoe (talk) to last version by Rodhullandemu) (undo) (cur | prev) 21:48, 13 August 2010 Foofinshoe (talk | contribs) (135,540 bytes) (undo) (cur | prev) 17:57, 13 August 2010 Rodhullandemu (talk | contribs) m (135,537 bytes) (Reverted edits by 220.255.54.79 (talk) to last version by PiRSquared17) (undo) (cur | prev) 17:56, 13 August 2010 220.255.54.79 (talk) (135,542 bytes) (undo) (cur | prev) 17:54, 13 August 2010 PiRSquared17 (talk | contribs) m (135,537 bytes) (Reverted edits by 220.255.54.79 (talk) to last version by Skysmith) (undo) (cur | prev) 17:53, 13 August 2010 220.255.54.79 (talk) (135,535 bytes) (undo) (cur | prev) 15:18, 13 August 2010 Skysmith (talk | contribs) (135,537 bytes) (discuss this in the talk page first.) (undo) (cur | prev) 15:09, 13 August 2010 67.84.9.155 (talk) (135,637 bytes) (undo) (cur | prev) 15:08, 13 August 2010 67.84.9.155 (talk) (135,634 bytes) (undo) (cur | prev) 06:01, 13 August 2010 PL290 (talk | contribs) (135,537 bytes) (Undid revision 378639914 by Fsuseminole17 (talk)) (undo) (cur | prev) 01:46, 13 August 2010 Fsuseminole17 (talk | contribs) (135,572 bytes) (→Magical Mystery Tour, White Album and Yellow Submarine) (undo) (cur | prev) 13:54, 12 August 2010 DC (talk | contribs) m (135,537 bytes) (Reverted edits by 124.168.232.189 (talk) to last version by SieBot) (undo) (cur | prev) 13:53, 12 August 2010 124.168.232.189 (talk) (135,540 bytes) (Fixed Spelling.) (undo) (cur | prev) 22:45, 10 August 2010 SieBot (talk | contribs) m (135,537 bytes) (robot Adding: zu:The beatles) (undo)
...one would see this:
(cur | prev) 14:37, 16 August 2010 Mclay1 (talk | contribs) m (135,528 bytes) (→External links) (undo) (4 revisions not shown) (cur | prev) 04:07, 14 August 2010 125.60.248.136 (talk) (135,560 bytes) (→Events leading up to final tour) (undo) (13 revisions not shown) (cur | prev) 22:45, 10 August 2010 SieBot (talk | contribs) m (135,537 bytes) (robot Adding: zu:The beatles) (undo)
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
Rob Lanphier wrote:
I've drafted this up here:
http://mediawiki.org/wiki/Pending_Changes_enwiki_trial/Reversion_collapsing
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]
There's a broader question about whether page histories should be "pure" or not. The history of what happened to a page might be unsightly, but tampering with it (or the public's view of it) can be dangerous.
MZMcBride
On Sun, Sep 12, 2010 at 1:25 PM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote:
I've drafted this up here:
http://mediawiki.org/wiki/Pending_Changes_enwiki_trial/Reversion_collapsing
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] [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=21860
We'll probably need to store the checksums. My read of the objections in bug 21860 looked like objections based on not having a clear use case (which this provides), fear that developers will start querying on the new field, and a refuted concern about possible MD5 collisions.
There's a broader question about whether page histories should be "pure" or not. The history of what happened to a page might be unsightly, but tampering with it (or the public's view of it) can be dangerous.
I don't think this is really tampering with the history; just with the presentation of the history.
It may be that, at first, the feature would need to be enabled on pages configured for Pending Changes, since that's where the need is the most acute. There's a lot of clamoring for "proper" rejection of a revision, where "proper" is "the revision doesn't show up in the revision history". If we implemented the request literally, there would be other people who would complain that we're destroying good faith edits, so we need them to show up somewhere. This would be a compromise; the revisions are still there in the db, but they aren't in everyone's face.
Rob
Rob Lanphier wrote:
We'll probably need to store the checksums. My read of the objections in bug 21860 looked like objections based on not having a clear use case (which this provides), fear that developers will start querying on the new field, and a refuted concern about possible MD5 collisions.
There's a broader question about whether page histories should be "pure" or not. The history of what happened to a page might be unsightly, but tampering with it (or the public's view of it) can be dangerous.
I don't think this is really tampering with the history; just with the presentation of the history.
It may be that, at first, the feature would need to be enabled on pages configured for Pending Changes, since that's where the need is the most acute. There's a lot of clamoring for "proper" rejection of a revision, where "proper" is "the revision doesn't show up in the revision history". If we implemented the request literally, there would be other people who would complain that we're destroying good faith edits, so we need them to show up somewhere. This would be a compromise; the revisions are still there in the db, but they aren't in everyone's face.
Rob
Note: See if this feature can help to the bigger goal of removing archive table and having anything there into a RevDeleted like system.
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.
At 2010-09-12 22:09, Rob Lanphier wrote:
[...]
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...
I think this could be done almost purely in Javascript. An extension or something would only need to add checksum of revisions to the page. The script would then collapse this onload. It could also collapse edits of the same user.
BTW. Wikia has something similar on recent changes. Not sure which extensions do they use.
Regards, Nux.
Rob Lanphier <robla <at> wikimedia.org> writes:
One general improvement we could make the history is to optionally collapse long stretches of reversions.
It would be nice if the system would be generic enough to be used for hiding minor bot edits (not necessarily reversions), which is a longstanding problem on all projects: automated edits with little or real content (disambiguations, interwiki maintenance, template parameter changes etc.) clutter up the page histories, often to the point where real edits take as little as 20-25% of the history, making it nearly unusable. (See also bug 11181 and 16228.)
https://bugzilla.wikimedia.org/show_bug.cgi?id=11181 https://bugzilla.wikimedia.org/show_bug.cgi?id=16228
2010/9/13 Tgr gtisza@gmail.com:
It would be nice if the system would be generic enough to be used for hiding minor bot edits (not necessarily reversions)
The only common factor between collapsing reversions and hiding minor and/or bot edits is the fact that you're hiding things from the history view. As far as detection goes, the two are completely separate problems: one requires a checksum to be added to the revision table, the other requires the minor/bot flags to be added to that table.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
2010/9/13 Tgr gtisza@gmail.com:
It would be nice if the system would be generic enough to be used for hiding minor bot edits (not necessarily reversions)
The only common factor between collapsing reversions and hiding minor and/or bot edits is the fact that you're hiding things from the history view. As far as detection goes, the two are completely separate problems: one requires a checksum to be added to the revision table, the other requires the minor/bot flags to be added to that table.
Roan Kattouw (Catrope)
Seems a good point to me. It should be designed right the first time, so it can easily be extended to handle all similar revision collapsings.
PS: The minor flag is already there.
Roan Kattouw <roan.kattouw <at> gmail.com> writes:
The only common factor between collapsing reversions and hiding minor and/or bot edits is the fact that you're hiding things from the history view.
Yes, it is the UI which could be reused.
the other requires the minor/bot flags to be added to that table.
Just checking for bot user group would be, while not ideal, still acceptable. Or is the table join required for that too costly?
On Wed, Sep 15, 2010 at 1:44 AM, Tgr gtisza@gmail.com wrote:
Just checking for bot user group would be, while not ideal, still acceptable. Or is the table join required for that too costly?
It shouldn't be a problem, but it wouldn't have the same functionality as the bot flag: 1) bots can mark some edits bot and not others, 2) multiple groups can have the right to mark edits bot. (1) is particularly important because there are some bots that specifically don't want to hide their edits, because they want human review.
wikitech-l@lists.wikimedia.org