FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Benin, National Day, Switzerland, Foundation of the Swiss Confederation

ModularizingRecentChanges

In a small wiki, RecentChanges is the heart of the wiki. It seems to elegantly combine so many facets of wiki life; collegial interaction; collaborative writing; a "list of subject headings" of new messages. However, when a wiki exceeds its CarryingCapacity, suddenly RecentChanges becomes an unweildy mess, and it seem very difficult to interact with the wiki in a meaningful way.

Perhaps the elegant unity of RecentChanges can only be sustained at low volume. Perhaps the different functions of RecentChanges can be decoupled. Maybe the modularized parts will be easier to scale. Or, at least, maybe some functions can continue to be fulfilled in large wikis, even if others cannot (rather than the present situation of losing all functions at once).

Different functions of RecentChanges

Peer review

Function
RecentChanges is a PeerReview mechanism. Everytime a change is made, every member of the community has a chance to approve or revert the change.

Other options
Perhaps a change doesn't need to be approved by everyone in order to permit effective community "control". Perhaps a change need only be shown to a subset of the community.

See also "Communal control of collaborative documents".

Communal control of collaborative documents

Function
On a wiki, the page database is a collection of documents or essays, or perhaps a single hypertext document, which is authored and edited by the entire community. The community has a sense of what is going on in the document, of what others are working on and what they are interested in, in what editing norms there are, of what others think of their work, of the personalities of others editing the documents, and of what the documents say. Most members of the community also have a subjective sense of ownership.

RecentChanges allows all of these things (hmm, looks like this "function" could be split into even more, smaller functions).

Other options
As mentioned above, perhaps a change doesn't need to be seen by everyone in order to permit effective community "control".

But which subset? Clearly, anyone should be able to subscribe to a page's changes (see SubscribedChanges, WikiFeatures:SubscribedChanges). But perhaps there also needs to be a minimal percentage of the active community involved in each change. Perhaps the community also must be "cross-seeded", with random people shown each change. If community members would prefer to only read a very narrow subset of pages, should we let this be, or should we ask them to review X pages a day outside their province, as a "duty"?

Scaling of this solution
How well this feature would scale depends on how much of the community must be notified of each Change in order to maintain "communal ownership of pages". This is an unknown social parameter.

"Subject headers" of messages

Function
RecentChanges is analogous to the index of messages in your inbox or in a newsgroup thread. In place of subject headers, the subject of each change is identified by the page it is on. When someone has a new idea (or a new questions) about something, they post it on the page "Something", and that is their way of saying, "Hey! I have a new idea about Something!". This is distinguished from other types of Changes, for instance, rewording/factoring/clarification, replying to someone else's comment, or some sort of meta-discussion like a personal argument or a discussion on whether some content should be moved.

Often you would like to follow changes to a page, but only when something new is being said. Or, often, vice-versa.

Other options
????. Maybe WikiFeatures:CategorizedEdit?

A sense of what's going on

Function
Because each community member sees all of the changes in RecentChanges, each member knows (in a small wiki) exactly what's going on everywhere in the wiki.

See also SharedAwarenessSystem.

Other options
See DigestedChanges.

Scaling of this solution
I don't know.

Broadcast announcements

Function
If a user wants to send a message to everyone on the wiki, or discuss something of importance to everyone (such as editing or social conventions), nothing special need be done; the message will be visible to all through RecentChanges

Other options
We could have a WikiFeatures:RecentAnnouncements, which would be a subset of RecentChanges which the user thought was important enough that everyone should read it.

Scaling of this solution
This feature would scale reasonably well, and with the addition of strict communal norms keeping the number of announcements down, it could scale very well.

Finding replies to your messages

Function
When you post something, whether a question or a comment, you are interested in replies to that post. Similarly, when you create a page, you are interested in people's response to it, even if you later otherwise lose interest in the subject matter of the page.

You also tend to "guard" your content to a degree, maybe not to the extent of resisting change, but at least you'd like to know when someone has changed your stuff. But this "guarding" function is closely related to "Communal control of collaborative documents", above.

Other options
This is essentially a MessageBased? behavior, and it can be served by old-fashioned MessagesBased? methods. Specifically, if wikis had WikiFeatures:threading (or WikiFeatures:FineGrainedAddressing), then you could subscribe to receive changes to or replies targeted at certain posts (or blocks of text) within a wiki page.

Scaling of this solution
This feature would scale very well.

Temporal facet of organization

Function
Some things make more sense with a linear temporal context. RecentChanges provides that, whereas most of the rest of wikis do not. So, when a linear event happens (which could be a conversation; an argument; a community decision), the linearity is mediated by RecentChanges.

Most observers agree that RecentChanges doesn't serve this function too well, even on smaller wikis.

Other options
Provide other linear contexts. For example, (web-archived) mailing lists which can be spawned at will, with little friction, when a new topic comes up. Or, what amounts to the same thing, a place to post threaded posts where refactoring is discouraged, at least for a few months. Encourage linear discussions, whether communal decisions, arguments, etc, to be had in the "linear zone", whereever that may be.

Scaling of this solution
I don't know.


Discussion

[new]

As usual, my focus is on avoiding InformationOverload. As you might have noticed, I seem to be getting more of an intuitive feel for the concept of modularization in software design, and I'm beginning to see all sorts of opportunities for more of it. I'm not so sure of this one yet, but since high-volume RecentChanges is such a big problem, I thought it deserved serious consideration.

This was prompted by my frustration with the higher volume of MeatballWiki's RecentChanges (or just lower volume of my time?) in the last few months. Between that and my own lack of time, I suddenly feel very lost there.


CategoryWikiTechnology

CategoryAttentionAllocation?

CategoryInformationManagement

Define external redirect: MessageBased CategoryAttentionAllocation MessagesBased

EditNearLinks: MeatballWiki PeerReview SubscribedChanges

Languages: