[Home]DigestedChanges

MeatballWiki | RecentChanges | Random Page | Indices | Categories

1. Summary

DigestedChanges is a WebLog of the wiki. For the current events of the day (i.e. what is appearing on RecentChanges), some chronicle or journalist writes a prose summary. This can already be done, since it is just writing, and has been attempted before on several wikis (e.g. MeatballDigest). The difference is that referring to page in a summary will collect all its RecentChanges beneath that summary. Unsummarized changes will be collected at the top until someone bothers to summarize them. In this way, whereas RecentChanges only provides pointwise data (which DigestedSummary attempts to solve), DigestedChanges provides a chronicle describing the story of the change(s) that provides context.

As another primary benefit, maintaining the digest is made more compelling, as providing up-to-date change information makes the digest more interesting to RecentChangesJunkies. Indeed, the economic value of the DigestedChanges is simply: combining the up-to-date change information with the ability to refactor RecentChanges.

Feedback on my still unclear summary

All truly creative work is the result of tension :) I'm unclear what you mean, though. I think I've always been unclear what DigestedChanges means, hence my preference for DigestedSummary. Perhaps a "user story" of how the system should work as several changes accrue might help? -- ChrisPurcell

DigestedChanges is exactly a weblog of the wiki plus one crucial addition. At the bottom of each entry, for all the links in the entry to pages on the wiki, we list the RecentChanges listing for those links. RecentChanges without an weblog entry describing them are displayed at the top. In this way, as yet undescribed links are obvious for people who want to write a weblog entry about them. -- SunirShah

ok, sleepy now. more later. -- sunir

RecentChanges is the most central page on a wiki, focusing the activity of the entire wiki into one presentation format. For small wikis, the low rate of PageChurn makes RecentChanges a tractable IndexingScheme for changes. However, as wikis grow in popularity and breadth, the number of unrelated topics that may get discussed in a given day increases. Further, as the complexity of the PageDatabase grows, the number of pages that may be touched in a given discussion grows as well, as discussions get split over multiple pages. Most RecentChanges implementations also collapse all changes to the same page into one listing, telling the casual RecentChangesJunkie only that the page has changed, not its full history over that time period which is often very important to know. Listing every change would quickly overwhelm the reader with InformationOverload, as certain editors often edit pages a dozen times or more until they are perfect. Moreover, there may be a large number of edits if the discussion is very hot, or if there is an EditWar, or if vandalism is in progress, or during a FlameWar, or during any other sort of ForestFire that is HijackingRecentChanges.

It isn't only the RecentChangesJunkies who suffer, but also casual visitors who only have time to catch up on the wiki once in a while. They cannot make heads or tails of what is going on, and this quickly breaks the social connections and CommunityLore necessary to hold the community together. After all, how is a casual reader to know that a major dramatic event happened if her best impression is that a smattering of pages were edited across a week or two, buried in a sea of other changes? She will never know. This can also lead to massive failures in SoftSecurity as PeerReviewers lose track of what is going on, and thus trust can evaporate.

Also, most RecentChanges implementations are programmatic renderings of the internal change log, rather than a simple wiki page like WikiWiki. This is done for many reasons, such as increasing the power of RecentChangesOptions as well as normalizing RecentChanges and automatically maintaining it. The trade off means that normal users cannot edit RecentChanges, making it an glaring exception a wiki. This also means that RecentChanges falls prey to any text that is not editable by PeerReviewers. Offensive text on the page is uneditable. Summaries are duplicated. The high-level picture is lost in the interwoven "UseNet"-style listing. And very importantly, noise is given the same precedence as signal, thus squashing the SignalToNoiseRatio of RecentChanges.

Of course, WikiWiki's RecentChanges is not really reworkable either, as the system will create new entries when older ones were deleted, and move older entries when they are modified again. And of course, you will violate the trust of the wiki if you bend reality by altering RecentChanges in significant ways. Interestingly, people have started to do this in bad faith (although SunirShah was the first known to bend Wiki:RecentChanges, albeit in good faith). This is why we do not let RecentChanges be editable.

The common solution so far has been to create a separate manual digest of the changes in some way; in a sense, an OnlineDiary of the wiki. These take several forms, like the original Wiki:ChangeSummary by CliffordAdams, the Wiki:ManualTopTen, and the MeatballDigest. These attempt to provide an edited summary of the events in more of a semantically ordered fashion rather than a chronological one. They may provide useful higher-order structure such as connecting a set of pages together in one description, giving the connecting narrative that caused them all to PageChurn. They also select out noise, ignoring or calling out explicitly pages that aren't worth reading by the casual reader.

Unfortunately, maintained by a lone curator most of the time, these attempts fail because they are forgotten. But they are useful as they provide meaningful information. So, why are the forgotten? RecentChanges is such a powerful sink that people will stick to it unless you provide something better, and that is very hard. Only when WikiWiki offered Wiki:QuickChanges did a significant number of people switch, if only because it was faster and reverse chronological. A manual listing is often worse because it is rarely timely. Further, it does not list all the changes, making it useless for PeerReview. Instead, it seems to be a duplication of information, and we want LessRedundancy.

Therefore, combine RecentChanges and the digest into one IndexingScheme. While a powerful concept, it isn't immediately clear how to do this. Further, we want to cover all the cases listed above.

Let us begin with an example data set. Here is the RecentChanges output for January 8, 2004 (all changes, including minor edits) ([skip below]):

January 8, 2004

This listing is ridiculously long and convoluted, and it is only one day. How would anyone visiting once a week have any idea what is going on? They won't, and they will leave. We can digest this, like so:

1. Summary
1.1. CategoryWikiTechnology
1.2. CategoryReworking
1.3. Socioeconomics
1.4. Meta
1.4.1. FlameWar
1.4.2. Culture
1.4.3. StyleGuide
1.4.4. New script development
1.4.5. People
1.4.6. Housecleaning
1.4.6.1. Fluff

1.1. CategoryWikiTechnology

1.2. CategoryReworking

MartinHarper works on CategoryReworking: RefactorAsYouGo? ThreadMess HitAndRunRefactoring ReworkingProblems WhatIsReworking RemoveIdentity RefactorLater?

1.3. Socioeconomics

1.4. Meta

1.4.1. FlameWar

Helmut and Sunir discuss the ongoing diplomatic problem on HelmutLeitner, after moving it off from the page (censored for this case) and MartinHarper's namepage. In the course of this, Sunir generated a matrix of various community to outsider relationships which he moved to UsAndThem. There was also a sidebar on the ongoing KeptPages failure that caused a bit of a misunderstanding. Sunir suggests a solution to the problem is to really DefendAgainstPassion by not requiring it.

1.4.2. Culture

Meatball talks more about itself, CategoryMeatball. YourOwnWikiCommunity? moves to MeatballAlternatives, including FermentWiki. We play with the MoreIntroductoryLinks? from MeatballWiki. We discuss the MeatballDigest on MeatballDigestDiscussion. Copyright and Meatball square off again. MeatballOpenContent? is redirected to OpenMeatballWiki. We learn a little more about PrimarilyPublicDomain and that CopyrightDoesntMatter in an OpenCulture. Spillover categorizes InfoAnarchyWiki. We also continue to debate CommunityMembership.

1.4.3. StyleGuide

Sunir suggests folding "see alsos" into the body text on the StyleGuide, using CommunityLore as an example. This led to moving the discussion of footnotes to ShallowPage.

1.4.4. New script development

ScottMoonen moves forward with replacing the UseModWiki script underlying MeatballWiki with an OddMuse script by AlexSchroeder, as he announced on MeatballWikiSoftwareDiscussion. For this Sunir gives him a BarnStar, which is related to the ongoing AwardRitual discussion.

1.4.5. People

SunirShah talks about joining LiveJournal in his diary for his KMD1002 class. He also fixes a longstanding bug with DeletedPage that required a lame blank line. Lots going on with MartinHarper, SteveDunlop?, HelmutLeitner. EarleMartin says hello again. LukeStark introduces his new ContactsMusicWiki. FlorenceDevouard joins MeatballWiki. Josef invites us to participate in UnitedDiversity's Open Space event.

1.4.6. Housecleaning

Martin and SteveDunlop? clean up some dead CategoryHomePages, particularly the CategoryRealNames cases: AlexBromfield, AredridelNiothke?, AvishalomShalit, KabAds?, LoriZ?-->LorraineLee, MatrixFrog?, PrinceOfStories?, PubWan, TecSpectr?, TheCunctator. They also delete WhyUseRealNames in an attempt to simplify UseRealNames. Along with this, the UseRealNamesDiscussion gets hit again, as well as WhatIsMultiplicity and SockPuppet. Also RecentVisitors, SillyTextFormattingRules, InformationWantsToBeFree have to have pseudonyms removed.

1.4.6.1. Fluff

There is also often only one RecentChanges. Some wikis provided SubscribedChanges to give users the necessary control to make their own RecentChanges. In a sense we have learnt from

The phenomena may include such things as alleviating flame wars by summarzing them faster.

"You need people." There are always people... you just have to give them an incentive.

The digest doesn't have to be singular either, so you can keep project journals over a longer time arc than RecentChanges. or even diaries.

it's literally a "wiki log"; i.e. a log of the wiki's transactions. 

<NamNT> and ppl __should__ provide a short summary too
<Sunir> per page? or per pages?
<NamNT> per edit
<Sunir> right... usemod wiki allows that; so does moin?
<NamNT> actually there is
<NamNT> a short "comment" field
<Sunir> but that doesn't help hold the whole story. people get lost after twenty changes happen in the discussion a day, since there is no temporality in a wiki.
<NamNT> it is limited though
<Sunir> right, so this is bigger, uniform, multi-paged, and atemporal.
<Sunir> it's literally "journalism" for the wiki. A "What's going on?" deal.
<Sunir> Which quite frankly, i need, because I don't read my own wiki that deeply. it's a waste of time.
...
<NamNT> make the comment field a bit bigger
<NamNT> so that it can accommodate a whole summarised story
<Sunir> maybe you're missing what I'm saying...
<NamNT> will that do it?
<Sunir> You write the story..


<NamNT> that really needs an active editor
<Sunir> sure, so does a wiki.

you just create a community expectation to create the digest. that's easier on MeatballWiki though. the fact that it tracks RecentChanges is a good way to get people to care. The previous solutions were built on top of recent changes, so no one cared.. people only read RC. this will supplant recent changes.

Think of it like this: why is RecentChanges the only page you cannot refactor? thread mode is evil. Recent changes is a poor man's thread mode.

For instance... I wanted to talk about maps.

"CategoryCartography was created to contain the field of CyberCartography?, which online is not so much the map of ObjectiveSpace?, but more SemanticSpace. We're driving towards SocialSemanticSpace?, such as with ChatCircles. Other interesting work includes StarryNight."

so, all those LinkPatterns [sic] refer to pages that are being changed (or will be changed). Underneath that summary on DigestedChanges the changes for those pages will appear...

Think of it like a weblog.. except the RecentChanges tracking is broken up per entry. To give an overall timeline of events, a shortened summarized timeline is presented in a column on the left. [it is a weblog.. but a *wiki* log; a weblog of the wiki's transactions]

Consider changes to those pages are same as current.

NamNT?: Displaying recent changes of all the pages in that page

except i can be slightly more magical by doing it per section using the table of contents and numbered headings and horizontal rules syntax we already have. although per page is easier to understand, it leads to a lot of pages, which may or may not be a bad thing. but it makes it harder to refactor two stories together, which will happen. but current wiki log incarnations have one page per entry, with comments simply appended in wiki fashion to those entries (draw a horizontal rule, start typing) so, maybe not a bad way to go for some people, or eventually.

Another advantage is that RSS for wikis today sucks.. RecentChanges is not what RSS is about; it's a spooge from one medium to another. This is a beautiful match.

does that feature need an editor to compile the changes? But since wiki culture revolves around RecentChanges, that will be easy to get. You cannot do a machine summary of the communication on a wiki because it is semantic. Anything to do with communication, you need a human to do.

Another advantage of DigestedChanges is that it is the wiki way to filter out noise. A lot of people want to use FilteredRecentChanges, by author, regex, domain, category, etc. Digested changes rather simplifies the information and organizes it; the same reason we use a wiki rather than a discussion board which is full of noise.

Economic incentive

Plus we have a lot of interest by weblogs

also, it helps gain attention to otherwise poorly understood conversations. If you are trying to pitch an idea, you can now provide a summary in one central location. The only other means was on your online diary, which didn't work as I was the only one with an online diary.

plus, if you can make RC as annoying as possible and DC as nice as possible, it can help.

CategoryWikiTechnology CategoryUnimplementedWikiTechnology

Some problems:

You could fix these without straying too far from the DigestedChanges scheme by having a very limited RecentChanges. It lists changes for a very short time in the past (I'd suggest 24 hours), doesn't display any change summary (it's not any kind of ThreadMode), and probably orders primarily by IP/username, placing newcomers at the top.

I'd like to see where you take DigestedChanges before adding any more of my own input. -- ChrisPurcell

I'm somewhat confused. Is this a proposal to make the RecentChanges list editable (and encourage people to edit it liberally), or to remove RecentChanges and replace it with MeatballDigest?

Yes. Both. Edit the RecentChanges into digests.

I'm all for DigestedChanges, but in addition to, not a replacement for, RecentChanges.

If people still read RecentChanges after the introduction of DigestedChanges, that would mean that DigestedChanges hasn't yet provided all of the functionality of RecentChanges. "Legislating away" our need for RecentChanges by removing it would only make some needs go unmet.

By the way, to me this is a special kind of WebLogDigest. The different ways to tell a story about what is going on in the wiki could be realized by multiple, separate DigestedChanges (ViewPoint again). Filtered recent changes is analogous to versions of DigestedChanges which don't mention every actual Change. -- BayleShanks

DigestedChanges is RecentChanges with more features. -- SunirShah

Sorry, didn't understand that. So it will be possible to see the "real", unedited changes, too? -- BayleShanks

Yes; that is imperative, otherwise it wouldn't be used. All the information of RecentChanges, but better organized. I need to write the text at the top of this page, but I am braindead. -- SunirShah

Looking at the sample DigestedChanges on this page, it seems to me that having text for each group of changes would be hard to manage (i.e. it would take too much effort to write for ephemeral changes, so no one would write it). However, even just grouping changes into a hierarchial tree structure would be valuable.

The question is, how to do this really really quickly?

If there is a fixed hierarchy, then assigning each change to its place in the hierarchy is just a matter of assigning it to one of list of categories (i.e. each place in the hierarchy is a "category"). So, this could be done via CategorizedEdits. The edit dialog for the DigestedChanges page could display each change with a set of boxes to the right of it. To assign the change to a different category, you edit the page, and then check one of the boxes next to that change. All changes could start out in the "uncategorized" category.

-- BayleShanks

At the SolaRoofWiki? we have a system of using PmWiki WikiGroups? that is not intended as a tree structure for organizing the principle NameSpace, which is our collective work on a knowledge base, but that are independent SubWiki and they each have thier own Recent Changes function. One of the WikeGroups? is our Profiles/User Name that is a grouping of our member's "homepages". Therefore I have referenced Recent Changes of pages in this group as "Member Activity" so that when new members create homepages or members make changes (or have their homepage edited by someone) then this shows as "Member Activity". We will also be establishing a "Feed" to these each homepage of a summary of newly written or edited WikiLog pages by that member. The individual member's logs have their own Recent Changes as do member's project space or personal WeWiki?. Therefore we can visit these different WikiGroups? and see the RecentChanges or be tipped off about changes of general interest by looking at Member Activity and non of this activity will drown out the important aspect of tracking changes and development of the knowledge base. We have much work to do on all these ideas - so we will look for help if anyone would like to get involved. - RichardNelson

This needn't imply a fixed hierarchy, actually. Imagine that the edit dialog offers the user a list of categories, sorted to put the recently-used ones at the top, or the opportunity to create a new one if it's really necessary. If you do create a new edit category, it's good form to say what it's a subcategory of, or at least provide a see also or was so someone else can put it into the hierarchy. And if you don't assign a category, RecentChanges provides a dead link so someone else can assign one.

-- NathanERasmussen

Discussion

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