I added bookmarking to MoinMoin:RecentChanges, so the system can hilight the pages that changed since you last looked (or actually, clicked on "update my bookmark"). The next step will be to change the "diff" links so that you do not get the last edit diff, but the diff between the version that was valid when you set your bookmark and the current version. Any further ideas to improve this? -- JürgenHermann
That's cool. Note that what you are suggesting requires VersionHistory, not just the EditCopy. FullVersionHistory? breaks the WikiNow. However, there is KeptPages, which I recommend over a full history. If the visitor hasn't viewed the diff in one expiry period, perhaps that's ok. That user isn't necessarily important anyway. As you should choose your expiry period to be sufficiently large that enough of the community can review the change, that user is probably not part of the community, implying that his or her case will be rare (or not worth the effort). Indeed, this kind of "long diff" seems very much in step with KeptPages. (Oh, how I love thee..) -- SunirShah
Even with expiry of old versions which will eventually creep into MoinMoin, as you already noted, it works for frequent visitors, which is enough for me (literally, it's a feature I've done for me me me ;). Others will get the "oldest stored version to current" diff, when no version older than their bookmark is available. -- JürgenHermann
Since UseModWiki stores user information server-side, perhaps you could automatically add entries to the user profile to indicate what was the latest version of each page visited.
The "diff to version older than my bookmark" feature is now in, and I really like it. What I hate lately in the C2 wiki is that if one single author edits a page over a period of time, you cannot see what he changed in the last 3 days on a page he kept editing for 2 weeks. -- JürgenHermann
I saw this page for the first time now. I don't know how much the "bookmark" feature is implemented in UseModWiki. However, I had added it to UseModWiki in my homepage. It acts similarly to that of MoinMoin. You can see it in [here]. (You have to register and login to use bookmark, because the bookmark timestamp is saved in each user's db in server) I wish it be helpful - UseMod:GyPark
RecentChanges and summary improvements: (pending)
Are the summaries useful? What should we be putting in them? Why would a minor edit need a summary?
Generally if there is a major edit to a page with an interesting title, I will read the page. The summary isn't helping me decide whether to read. If I want to know what has changed, a diff is more reliable. -- DaveHarris
Summaries are not very useful given the current level of traffic. I suggest using them to either draw attention to substantial edits, or to notify a user of less-interesting changes (like rearranging text without significant additions). I suggest summarizing the changes rather than the entire page.
Summaries may be useful with minor edits to indicate the kind of change, so a later reviewer can easily skip uninteresting edits. (For instance, if a range of edits are all summarized as "Category XP", I might sample a few at random, but I wouldn't check all the changes.)
Some people will not use the "diff" feature. Summaries may be especially useful when making non-obvious edits in the middle of pages. Finally, I'm not completely happy with "Summary"--maybe it should be changed to something like "Change Notes"? --CliffordAdams
They're more useful if this Wiki had full history because then they'd function as check in comments for a versioning system. As it stands, they are only for RecentChanges. Kind of extra advertising, especially useful for pages with boring names. For instance, the summary I made for this edit was "Baywatch." -- SunirShah
If I habitually skipped all changes with the summary "Baywatch", I would have missed Clifford's comment. I am comming to the conclusion that adding a change to RecentChanges should not cause the previous change to be removed. -- DaveHarris
I think it would help for a couple of reasons. First, it would make clear what the hot pages are for the day, as there would be many entries for that page. Second, and more importantly, it wouldn't inhibit minor edits. As it is now, I hesitate to make minor edits to things on RecentChanges, as it removes the information provided by QuickDiff?.
The (n changes) entry on RecentChanges does this for you. It tells you how many times the page has changed in the RecentChanges timespan (1, 3, 7, 30 or 90 day(s)). The higher the number, the hotter the page... -- SunirShah
Given the multiple requests to display all changes, I will add this as a feature. (You can already display all changes using the RecentChangesOptions, but it is not very usable.) I'm currently considering something like:
June 8, 2000
June 7, 2000
...and I may make it the default for RecentChanges. This would make the summary lines more useful, and allow people to easily see which pages are popular. User preferences will eventually allow much more customization, but this may help in the meantime. --CliffordAdams
I like it. I think that listing the multiple entries under the same page name is even better than just leaving the page name where it was and adding a the name again at the bottom. Your example conveys much more information at a glance than the RecentChanges on WardsWiki.
I like this too (provided it was collapsable to (n changes)for those hardcore junkies like me). UserName is evil. -- SunirShah
I am not sure grouping the changes by page is good. It is more verbose, in that it adds a line to the display. It loses information about the order in which the edits happen. It just seems more complex. I'm not sure it is solving a real problem. Have you tried the simpler list? -- DaveHarris
Can we try it as an experiment? If it turns out to not help, then lets get rid of it. I thought of the problem of being verbose as well, but even at my usual connect speed of 26400 at home, the long RecentChanges on WardsWiki comes down in just a couple of seconds. Keeping history may add a small amount to that. (I do not know how many pages have multiple edits, but I suspect it is less than half, and just a few have more than a couple of edits on a given day.)
By verbose I meant that specific format, which added a line per page. I am not bothered about the verbosity of showing all the changes. Although perhaps consecutive changes by the same person should be collapsed. See below. -- DaveHarris
A ChangesViewsQuotient? on RecentChanges instead of only changes would enhance the use value. E.g. "4/20" meaning: "4 changes, 20 views" -- fp
I don't think the number of views is important enough to be listed on RecentChanges. --CliffordAdams
Here's the steps to reproduce the problem.
All is good. Continue:
All is not good. The summary was blasted during the minor edit. -- SunirShah
why is it that sometimes pages appear on RecentChanges without an (n changes) link? for instance, right now RatingAsContent and WikiVoting are both on RecentChanges, yet with no (n changes) next to them. However, the changes can still be accessed by action=history (via the "View other revisions" link on the pages themselves). (perhaps this happens when there is only 1 change? in this case this is a suggestion rather than a bug. the suggestion, namely: add a similar feature for single changes)-- BayleShanks
If you look at all changes MeatBall:action=rc&all=1 you will see n entries on RecentChanges for your particular configuration. Try changing it from 1 day to 3 days to see how n increases or decreases. -- SunirShah
thanks. so now my suggestion is have an option that puts "(n changes)" next to every item, so that there is an easy way to go right to the action=history version of each page. -- BayleShanks
I am considering whether to replace the (diff) link with a link to history a la Tavi, as the new Tavi-style history includes the diff already, so it's almost redundant to have both. I haven't asked people about the idea yet because I want to improve the history interface still. Conceivably, I can unify the two functions. This will improve the FeatureKarma of the software in my opinion. -- SunirShah
I'd still want to see the full page displayed below the diffs - it lets me see the full context. Idea: change the "Added: 61a62,65" diff headings into links to corresponding page anchors within the full text. That would be useful! -- EricScheid
In retrospect, that's so painfully obvious it hurts. Excellent idea, Eric! We should definitely implement this. I want to add Alex's UseMod:WikiPatches/AccessibleDiffs before I leave for Europe as well, so maybe we can combine the two. -- SunirShah
One more minor enhancement -- if multiple diffs are being listed on RecentChanges, make the (diff) link do a comparison specific to which diff it was ... ie. use the links which are accessible in View Other Revisions. This makes it quick and easy to see who made what change. -- EricScheid
I'm considering setting up a blog alongside the wiki, integrating the two. I imagine it being implemented as a 5 line text box on the edit page, so people could just cut & paste the more provocative edits. This textbox would then get pre-pended onto the blog page along with the the users name and an automatic link to the page just edited. The blog page itself wouldn't be editable so as to avoid splitting the discussion.
Alternatively, you could just create a discussion page that is maintained manually like ZWiki. (I think it's a pretty wiki solution.) -- SunirShah
See also WikiLog.
Why does the latest version of a page always have to be the current version? Since WikiSpam is becoming more common, why should the last user to change a page choose what is the current version of the page. Why not let the reader choose if a recent change is acceptable. When a page is changed, how about adding a link at the top of the page to advise the reader that the page has been changed recently, and needs a PeerReview. When enough suitable readers have read the page and found it acceptable, only then does the change become the current version.
Any user should be able to flag a change as unacceptable (eg Spam, irrelevant content etc.) Changes rated as unacceptable would remain as proposed or pending changes until the page is edited again, then drop to being an old revision or could even be purged depending on an unacceptability rating system. Currently this is done by reverting a page - a complex process.
Changes rated as acceptable by a suitable number of different readers/reviewers get accepted. I am thinking of a jury of (say) the first 12 different (identifiable) users who review the changes and find them acceptable. Reviewers could even be weighted (or rated) depending on their reliability. The vote of a reviewer who's opinion always agrees with the majority of a reviewing jury could rate higher than an anonymous or untested reviewer while reviewers who go against the majority consistently, or try to review their own work are given little or no weight, apart from reverting the page to undo a change they have proposed.
The wiki itself could learn what is unacceptable. Users who repeatedly submit the same unacceptable changes could find all their submissions ranked as unacceptable (or suspect) by the wiki itself. Users who consistently submit acceptable changes could acquire a level of trusted status.
Some changes, such as an addition with no deletions could require far less [[PeerReview]]s than the replacement of a page of text. Similarly, small changes, say a few characters, a word or a line could be considered acceptable minor edits. Also pending changes could be ranked on a percentage basis of the amount of change made to the page, with recent changes only showing pages changed above a certain percentage.
The RecentChanges log could show any proposed or pending changes in a separate pending changes section or flag them as pending review.
This scheme probably sounds a lot more complex than it need be. The simplest solution would be to provide a mechanism to easily revert the page(s) and not have the latest spam survive in the page history.
CategoryWikiTechnology CategoryRecentChanges CategoryMeatballWikiSuggestion