[Home]EditDigest

MeatballWiki | RecentChanges | Random Page | Indices | Categories
The mechanics of a wiki (see WhatIsaWiki) typically result in the community focussing on RecentChanges. Historically, this was simply a list of recently-changed pages; however, unless one is a RecentChangesJunkie, it is difficult to follow the quick flow of discussion, or to decide how to usefully spend the limited time one has available. Adding a summary to each change again benefits mainly RecentChangesJunkies, as only the most recent summary will be displayed. Choosing to see all changes, rather than changed pages, is a step closer, but results in InformationOverload. Summarizing such a large set of changes is best done by the wiki editors, not a machine.

Therefore, add a description of your changes to the page summary. To keep the summary fresh, remove descriptions of changes older than the PeerReview period of two weeks. To keep the summary informative and useful, digest it when it gets too long.

But, these points are merely guidelines, not hard-and-fast rules: DigestedSummary is an on-going experiment, and we welcome experimentation and ideas in this space. For instance, one useful pattern that has emerged is using the digest field as a kind of MiniBlog?, letting people know when a WebLog-like page has updated. In these cases, one can delete older entries from the digest entirely, as readers only need to see the latest entry to know new entries have been added. Cutting out the older entries, even if they are only a few hours old, is a neat way of preventing a hot MiniBlog? from HijackingRecentChanges.

How EditDigest works

During active discussions, certain pages are modified several times in one day, which is displayed on RecentChanges as only one entry in the listing (unless you request to see all changes). This means that readers coming much later are often unaware of what has gone on during the day or even the week. A ChangeSummary? provides a short amount of metadata about each change to help those who are skimming RecentChanges to tell quickly what has past. However, as described, this only helps them for the last change, not the whole history of changes, so only RecentChangesJunkies are given an opportunity to understand what has happened. We do not like junkies; they bring too much social pressure to the wiki. We want to allow people to remain away from the site as much as is reasonable for them to still contribute without wasting their time keeping up to date with each micro-contribution. Listing all the summaries underneath each page's entry in RecentChanges leads to a lot of unrelated and redundant entries that could be simplified, especially when someone enters an edit & view & save cycle, creating multiple new versions with the same summary.

A community solution is to preserve the summary between edits. This contrasts the previous situation where new summaries are created for each edit, even successive edits by the same author. New interesting changes can be appended to this summary as a running discussion. The summary field becomes a digest of the changes to the page, a chronicle (journal article, GroupWeblog?) of what has transpired on that page in recent history. Really old or irrelevant happenings can be manually removed, and new interesting things can be appended in a natural way (rather than simple sequential listing). This is closer to the wiki way where everything can be refactored.

Since RecentChanges is not a part of the WikiNow, but a mechanism to enable PeerReview and community, it makes sense to start a new summary when the last revision is old (say, the KeptPages timeout).

Implementing this is as simple as enlarging the summary box, renaming it to "Digest", and filling the field with the previous summary.

See also DigestedChanges.

CategoryWikiTechnology CategoryUncommonWikiTechnology CategoryRecentChanges

A medley of thoughts and comments

Summary Life-Span

On EmacsWiki:2005-05-01 I have a user reporting that most people don't actually change the summary, resulting in misleading summaries. I'm not yet sure how to deal with it -- maybe the old summary is in fact what low frequency readers (like Bayle or Scott) would expect. Then it is just a matter of re-interpreting what the summary is all about. As a workaround I suggested to further reduce the "summary life-span" to a mere two or three days -- much shorter than the kept pages expiry. After some more discussion I decided to reduce the summary life-span to four hours.

-- AlexSchroeder

Have you updated the text introducing the summary field? I would also suggest shrinking the size of the edit fields. On most browsers you won't even see the digest field unless you know to look for it, because it's so far down the page; and is there any point having an 80-line digest edit field when a summary that big would swamp RecentChanges? -- ChrisPurcell

Well, I have people explicitly saying that they don't want a summary of what is going on -- they want a comment on the last edit only... I tried to explain the concept without renaming the field. But I don't think they like it.

As for the size of the summary field, I think your browser is failing to take note of the CSS I'm using -- my edit field is three lines high. I really should test in some other browsers, too. On IE at work the edit field is two lines high. I wonder what you are using. -- AlexSchroeder

[The CSS you're using] dictates "textarea { width:100%; height:80%; }". That's probably the problem right there: Safari uses the height tag of the CSS, not the HTML. -- ChrisPurcell

Ah, I will test in Safari when I get back home. I also use the following, now: 

    textarea[name="text"] { width:100%; height:80%; }
    textarea[name="summary"] { width:100%; height:3em; }

Automatic Summary Composition

Looking at how a typical RecentChanges entry looks like, I note a pattern:

(Costin) back to Adam Smith (Helmut) Added a reference to WikiIsParadoxical. Some additional criticism. (Costin) In favor of MinimalistLaw as a self-evident principle.

What I see is that we have adopted as a convention not a "digested summary" but the concatenation of edit summaries. It seems to me that we could just concatenate a small number of old-style edit summaries, prefix each with the respective author, and get the same result.

(none)
In favor of MinimalistLaw as a self-evident principle.
Added a reference to WikiIsParadoxical. Some additional criticism.

Turn it into:

ChrisPurcell
CostinCozianu: In favor of MinimalistLaw as a self-evident principle.
HelmutLeitner: Added a reference to WikiIsParadoxical. Some additional criticism.

Instead of what we have now (see example above).

-- AlexSchroeder

DigestedSummary has that as a degenerate behaviour, yes. If the summaries are short, what would be the benefit of digesting them? However, in the faster-moving pages, the summary is actually being digested.

You also lose the benefit of retroactive digest-spam correction if you merely concatenate. Would we really want a spammer's "poo to you" on RecentChanges indefinitely?

(You also missed my CopyEdit changes in your example :) -- ChrisPurcell

Heh. I was only interested in major changes, of course. -- AlexSchroeder

About the new style of RecentChanges

Saw you asked the question about why another person did not like it. Well, in my case, I will like it better if I can use a 1 line display like before. Sometimes it is better to use the new format, if the digested summary has lots of stuff in it. Thanks for listening -- DavidLiu

Thank for commenting, David! While I will revert back to the old format if people want, I want to give everyone a chance to see the new format and comment. Any change is therefore deliberately going to be glacial. -- ChrisPurcell

I was a bit harsh earlier, but yes I do like the new design "too".

-- DavidLiu

On the theory that the main problem with the alternate scheme was it being too busy, I've changed it again. This time, the digests are not emboldened, only on a gray background. (I promise that it's easy to restore the original!) -- ChrisPurcell

Does the digest blank itself automatically after a few changes, or what?

To be honest, I prefer the old system. -- EarleMartin

The digest resets after a period of inactivity - see DigestedSummary. -- ChrisPurcell

So. At present, the digest says "Earle, Sunir and Alex provide some feedback for this feature". Should I now... add something, since I'm replying to you? Replace it entirely? Or leave it, since it already covers this discussion we're having?

I think what I don't like about this is that it makes me hesitate before saving a page. The older system was a no-brainer. -- EarleMartin

I know, it's awkward. However, we set out to provide a better, digested RecentChanges, and that's always going to involve thought, no matter the system. The question is, is there a way of doing this that involves less pain, or is the pain minimal? -- ChrisPurcell

I'm not sure I'm grokking how this works either. I am feeling strongly it's somehow the wrong way around. Individual edits are individual, and need individual summaries. I am still interested in a global summary for a collection of changes (DigestedChanges). (apparently) Ward originally intended Wiki:RecentChanges to work this way, which is encouraging. -- SunirShah

I've not seen any implementation of DigestedChanges that is actually maintained. If it was possible, it would have worked for Wiki:TheSimplestThingThatWorks, namely editing Wiki:RecentChanges. I suspect that, unless everything needed to make an edit is on a single page, the "extra" bits will rapidly be forgotten. -- ChrisPurcell

The one problem I am seeing right now is that there are two types of change summaries. The summary for this change, and the summary for the collection of changes that comprise the event. I find myself not writing summaries for my edits, which makes PeerReview harder, I think. If we did DigestedSummary instead for each section on DigestedChanges that refers to this page, that would make a lot more sense. And at least with DigestedChanges, the DigestedSummary would be for all the pages involved in this event at once (almost like a SuperPage?). -- SunirShah

Hmm. I find that in my workflow at least, PeerReview means looking at a diff. I pick the version to diff against based on the last version of the page I remember seeing and approving (at least when KeptPages hasn't failed). An edit summary has never been a part of that for me. I'd be interested in technology that made it easier to validate the most sensible diff. Does that agree with other people's experience? -- ChrisPurcell

I think there's value in writing summaries of each change. I will admit that this doesn't have to be a special interface, merely a convention. Making point form notes that can later be reworked once they resolve into something coherent. Suppose the summary was parsed as WikiSyntax? I admit this is a pain with UseModWiki. -- SunirShah

One can have a social convention now - just add your change to the digest ;) We can always throw together a special syntax if an actual convention emerges. (The code already supports preceding categorized edits by an asterisk.) -- ChrisPurcell

It doesn't support it. Watch. -- SunirShah

I've explained myself badly. I meant that if you precede a categorized edit by an asterisk, or follow it with punctuation, e.g. "* [CopyEdit: some copy-editing];", then the preceding asterisk and following punctuation are removed alongside the categorized bit. I did this because I've seen several occasions where asterisks, pluses, etc. are used to separate categorized edits, and it wouldn't make sense for them to remain visible. Similarly, if asterisk becomes a conventional way of separating non-digested updates, we can make markup to support it. (I did this in one of the original prototypes.)

What would also be quite helpful would be to keep carriage returns in the digest. I'm not sure why they're filtered out, so am not going to fix this without consultation. -- Chris

I've been away from MeatballWiki for some time and came back to find the new format for recent changes. Is this the page that describes the current situation? If so, could someone clear on all the interactions rework this page to get rid of all the confusing bits? I don't feel I know the history well enough to do so myself. Just seems that people are referring to many different iterations of solutions, many of which do not exist anymore. -- TedErnst

Done. I think most of it still applies. -- ChrisPurcell

Maybe a solution to the confusion about how to use the summary, as well as how MinorEdits tend to obliterate the summary, not to mention my reluctance to edit the summary now when I can't figure out what it is saying, is to have two summary fields. Have a one-liner for the current change, which can be applied to minor edits if so chosen. Return the MinorEdit checkbox. Have a textarea for the global summary. I think I actually proposed this before, w.r.t. DigestedChanges. -- SunirShah

That'll make the history page neater. It'll probably also mean people don't update the digest, because they start having to write everything in triplicate. I also refuse to sanction minor edits :) I've seen lots of people not even use the summary field when it's a simple edit summary, so why worry? Just point people to the HowTo. -- ChrisPurcell

I don't like 'digested summary'. I think I said so before, but it's been lost. Two objections: It makes the editing process more hard work. This is not good for wiki newbies, for whom even the simplistic idea of entering an edit summary is too much to bother with. The page history display becomes cluttered with long summaries, where before we had a few words appearing next to some of the edits. Basically the whole wiki design loses some of its elegant simplicity. I can see some advantages however, and so it makes sense to experiment with it here on meatball, where most of us are experienced wiki users, open to new ideas/features. I'm surprised the group has stuck with it for so long though.

Anyway I notice the OddMuse engine developers have adopted this now, which means new wikis will start appearing on the web, with this design modification. Was that the intention? It's a step backwards if you ask me. -- HarryWood

I agree with you on page histories: they need work. I'll put the time in sometime soon. However, I think the audience deserves infinitely more consideration than newbies, for two reasons: one, newbies quickly stop being newbies, while the audience stays an audience forever; two, PeerReview can handily correct summarization mistakes just as it can spelling errors. -- ChrisPurcell

I also noticed this with a recent OddMuse update and have no experience with it outside that. OddMuse's implementation seems pretty confusing and inconsistent to me. Until being told about this page explaining what is going on it was really strange. Revision notes were now sticky but only sometimes. The new multiline revision notes text box was one of the first things I noticed that seemed odd. It always used to be a summary/short note, you don't need a lot of room. Some of this I am sure is due to the implementation and can be improved, but being consistent is important.

What I found really annoying is that new edits sometimes loaded up the revision notes with the newly added text including any formatting codes or links. Where I have noticed it is a spammer's edit and they are likely just loading any textarea with their identical spam. Whatever the cause it certainly clutters up the revision history. If this is caused by the spammer attacking any textarea it certainly should be something to think about. How easy is it to revert an overwritten digest summary?

I don't know that I agree with Harry's worry about newbies. They can and probably will just ignore it since they won't understand it. I think that actually extends to most everyone, not for misunderstanding it, but because it is inconvenient. A few words for a summary is usually all that a revision needs. That isn't really useful for an RSS feed though. Other than the RSS feed use of the digest, it reminds me of the talk pages of MediaWiki. Talk pages are good for some wikis, others don't need them. I think DigestedSummary may be like that, I hope it is optional if it stays around. Of course, now it would have to be backward compatible with the digest for those who got it in an upgraded. Truncating would be good enough probably since those who would be going back to the old way probably didn't use the digest as intended.

It may have already been suggested, but an alternative that could provide something for the feed is to concatenate the edit summaries from the last several edits (based on a similar time scale DigestedSummary is already using). People would have to make their edit summaries a bit more descriptive, but either way things are changing that people will have to get used to. -- JoeChongq?

While one can't remove a spammer's digest summary from the page history (too vulnerable to contrariwise abuse), one can remove it from RecentChanges. This is not possible if one merely concatenates edit summaries. (This has been mentioned above, so is probably a good point to keep when rewriting this all into DocumentMode.)

If your OddMuse-using community is finding it hard to adapt to a DigestedSummary, try leading by doing! When you've PeerReviewed the changes made to a page, jump in and write a decent digest if the last authors haven't. One doesn't need to edit the page text (beyond adding a carriage return somewhere to avoid being treated as a no-op) to neaten the digest, though spelling corrections are always another good PeerReview task. -- ChrisPurcell

Comment moved to DigestedSummaryEmpiricalResults

This is mostly copied over from [our wiki] where we were discussing how digests affect [WikiMinion], RichardP?'s antispam bot. WikiMinion? currently uses the summary field to note what action it took (such as revision it reverted to) so that a human can more easily diagnose and correct mistakes made by the robot. Richard said "only one or two wikis protected by WikiMinion? are running a new version of OddMuse (and hence are now theoretically using digested summaries) and they're so low traffic that they're pretty much always behave like a wiki that does not use digested summaries."

Assuming that digesting is extended to other wikis such as MediaWiki, especially Wikipedia since they use a number of bots for various purposes, there needs to be some standard way for bots to leave information. A bot is not capable of writing a proper digest, all it can do is overwrite or append to the previous digest.

The edit page here mentions a way of recording non discussion changes like this by using brackets.

Bracket copy editing or spam reversion with [CopyEdit: ...] or [WikiSpam: ...]

But I really don't think that information belongs in the digest. The purpose of the digest is for giving an understanding what has been going on lately on the page and providing a meaningful RSS feed. For those purposes the digest is good if used as intended. I don't think information about copy editing and spam cleaning belong in the digest, but there is no other way of recording that they took place. They didn't add anything to the discussion or evolution of the page so why should they be included in the digest?

While overall revision history may be more informative, page histories are less informative. The revision histories are no longer relevant to a single revision anymore. Instead of looking at short notes you must read the longer digests and find what changed between them to locate the revision you want. Are we going to need digest history diffs? That wouldn't even make sense. -- JoeChongq?

You must remember that on MB, brackets like this are automatically filtered out from the RSS feed, and also from RecentChanges for most viewers. Take a look at EditCategories. -- ChrisPurcell

This will be only my third edit here in many months so I am mainly only familiar with the OddMuse implementation which apparently has a way to go to catch up with MB. Once the bracket filter is added to OM that will solve the bot problem I think. We also found that the expire time on digest summaries on OM is only 4 hours. For even a well traveled wiki that is probably too short, it certainly is for even a moderately used wiki if digests are to be used as intended. -- JoeChongq?

Where should "digestion" happen?

ChrisPurcell said on DigestedSummaryEmpiricalResults that the history page may be the right place.

When people edit a page, their first reaction is to write a log entry into the summary field. They summarize their change only, by adding their text, or they think their change does not require any explanation. The actual numbers are 44% and 15% respectively, but we need to account for the fact that 29% of the changes where follow-on changes, ie. the same author deemed it unnecessary to write a summary, which might indicate that the the actual ratios are 44/71 and 15/71 instead of 44% and 15%.

It seems to me that the ones editing the pages are not really interested in summarizing recent discussions in the summary field of a page.

Nevertheless, there seems to be interest in providing such summaries. RareVisitor?s would like to see them on recent changes. So that leaves us with two questions: Who would write them, and where would they write these summaries? If we assume that those summarizing the activities are not the ones writing the page, then I think it should be ovious that the edit page is not the right place to do it. Furthermore, many wiki implementations will not save an edit unless the text of the page has changed. There is a place where we can look at changes to a single page, the history page. If we could edit the current summary (overwriting the summary for the last edit) right there, then maybe that would give the right people the right information to write the summary, and put the summary where the rare visitors will actually see them: On the last edit visible on RecentChanges. -- AlexSchroeder

A trio of thoughts: (1) Any wiki implementation will save an edit if you program it to - simply allow all posts from the history page to succeed. (2) If you overwrite the last log, you remove the AuditTrail and any ability to revert spam digests, so that's out. (3) The numbers on this page do not support your conclusion that "the ones editing the pages are not really interested in summarizing recent discussions", just as they do not disprove it. -- ChrisPurcell

I agree with your point about spam reverting, if the summary is a target for spam or vandalism. As for the numbers, where do you disagree? It seems to me that 44% just added to the summary, 15% did not provide any, 3% digested it, and we can ignore the others (misuse, spam, and follow on changes). -- AlexSchroeder

The numbers don't tell us which summaries were digested. StableCopyEmpiricalResults tells us that 90% of unstable periods probably don't need summarization - being too short - and even for the remaining 10%, summarization is certainly not needed on every edit. During the longer unstable periods, digestion can be as simple as merely adding a little to an existing sentence, which is counted as an addition by the algorithm I used. -- ChrisPurcell

A logical next step is to allow arbitrary wiki syntax in the summary field. We would then 1) parse this syntax on the history page; 2) parse it on RecentChanges; and 3) emit it in the RSS as CDATA rather than raw text. The net effect is that, if you choose to use the summary in such a way, you can make your RecentChanges and RSS much more bloglike.

Request For Comment (April 29, 2009)

EditDigests have been a part of MB for nearly four years now (wow). Concurrent with the comments above, I made other changes to MB to support digests, notable EditCategories replacing MinorEdits, and a greatly reworked History page with integrate page diffs, showing EditDigest diffs. So my question to the current MB community is: do you think these changes have worked out for the better? Is RecentChanges now better for non-RecentChangesJunkies? Is doing peer review easier? -- ChrisPurcell

CommunityWiki has not been as active as it once was, but we've been using them as well. My own verdict is very clear: Edit digests clearly work! -- LionKimbro

I'm mostly a lurker, but I have to admit I main look at the author and then the actual page diff. Although the digests don't get in the way, they aren't a large difference to me. -- RadomirDopieralski

Does the History page make this workflow convenient? --ChrisPurcell

The history page is excellent, much better than in any other wiki I know, the only thing I miss is a 'revert' button for fast despamming, but I'm well aware of why it's not made that easy. -- RadomirDopieralski

I haven't been here very long, but I have to say I really like the way the history page works here compared with the UseMod system. -- NathanielThurston

I like it and find it useful. If you are considering any enhancements, I would find it very useful to be able to receive the digest as part of an RssFeed?. -- HansWobbe

I am a fan of it. Chris, it was you, to help me detect its benefits. Unfortunately there are some people here, who are not yet aware of this gem. -- FridemarPache

Does the RSS feed link on RecentChanges not work for you, Hans? -- ChrisPurcell

Chris - Sincere apologies for a erroneous error report. Your response prompted me to look at my automated procedures and I found the "glitch" that was causing my problem. Thanks for responding. -- HansWobbe.

Coming here rarely, I am always a bit confused about things. I'm sure it's easy to look up, but since you're asking for input from non-RecentChangesJunkies for Meatball, I would have to read up on EditCategories every singe time and never do. Effectively I no longer know how to make minor changes and am bewildered by the line "Bracket copy editing or spam reversion with [CopyEdit: ...] or [WikiSpam: ...] (see EditCategories)."

As for the history pages, I'm unhappy in how they break my established work pattern. I usually look at RecentChanges and click on the diff links for pages. In Oddmuse, I can see the diff, and read the rest of the page. When I look at the [TeaTime diff], I don't even know where to click in order to look at the real page. It took me several seconds and two scrolling up and down, trying to find a link in the header or footer, until I realized that I needed to click on the top-most time ("1:37 pm") in order to view the current revision. I don't like how Oddmuse shows the diff followed by the page text, because it makes it hard to understand context in large pages. On Meatball, this is made even more difficult because I have to read the diff, scroll back to the top, click the timestamp, and now find the phrases I remember from the previous page to get some context.

If anybody wants to contact me regarding the above feedback, feel free to mail or instant messaging; I'm not a regular reader on this site anymore. -- AlexSchroeder

---

Usability suggestion for making things newbie-friendly without any fundamental change to the system: Only show the EditDigest if the user checks an "Advanced" checkbox. By default, show something that looks more like a traditional Wiki (EditSummary?, CopyEdit checkbox). Stick whatever is written in there on the end of the EditDigest (in a CopyEdit segment if the checkbox is selected). -- AlicePurcell?

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: