Shouldn't this be on HijackingRecentChanges?
Both doesn't seem to be general enough, perhaps RecentChangesAbuse??
You're perfectly right. HijackingRecentChanges is only one abuse, and these two are additional abuses.
The fundamental problem is that RecentChanges is algorithmically generated, and thus it cannot be edited. DigestedChanges solves that problem. Noise pages can be swept aside. -- SunirShah
There are a number of wiki engines (PhpWiki, WardsWiki, PmWiki) that have RecentChanges as normal editable text but this hardly solves the problem. RecentChanges should be an efficient interface for a wiki user to see what is going on and which page changes to check for PeerReview or because of interest. To make it efficient technical features (e. g. like minor edits, summaries, usernames) and social behaviour (e. g. correct use of minor edits, good summary, use of a name) have to go hand in hand. Coming from looking at WardsWiki problems are visible: minor edits turned off (probably because of misuse), no summary feature, only few users bother to be visible with their username, no direct diff access (no diff+page). -- HelmutLeitner
I think the difference between DigestedChanges and editable RecentChanges is that, one, it's difficult to edit RecentChanges between edits. Two, if you edit RecentChanges, newer changes to the summarized pages are appended. Three, people are loathe to edit RecentChanges for fear of violating OpenProcess, since RecentChanges is the AuditTrail of the site. DigestedChanges does not suffer from these problems. It preserves the AuditTrail, but makes it easier to combine a set of changes into one. The real test would be to implement it as a replacement for RecentChanges here on MeatballWiki. -- SunirShah