CriticismOfWiki

claim / summary

The page criticism of wiki is for critical remarks about wiki. For the positive aspects of wiki see praise of wiki.

Things that often fail in wikis:

In Greater Detail

Publicizing – There's no easy way to keep a public side and a not-public (but not interested in private here) side. Who does this right? KuroShin? does an amazing job of it. The interior is the "Diaries" section. The public part is "post to front page."

The reason people don't know about what we do in wiki isn't because our ideas are bad. It's because we don't release anything for public consumption! Blog writers (A) work very hard to make sure things are up-to-snuff, and then (B) release it.

Sometimes, we work hard to make sure something is up-to-snuff for public consumption. (Meeting condition A.) But then do we "release" it? No.

RecentChanges does not count. RecentChanges is so filled with intra-community communications, small edits, messages for John, etc., that when we do make jewels, nobody can find them in all the rough.

We know the solution, BlogControlledByWiki. (Roughly.) It works great for KuroShin?. But there is no infrastructure to get around this problem. (See: "Inflexibility – Simplicity," down below.)

Just let people talk. – Usually what you do, is this: Someone gets a big idea. They create a new page, and describe the idea a lot on the top. Then other people comment. This is par for the course, on SlashDot? and KuroShin? and Drupal & other sites, no? Oh: And on C2, CommunityWiki, and various other wiki. But on Wiki, we discourage creating new pages, because pages build on pages and we don't want DeepDisagreements?, and because we are economizing on new pages because we dream that we'll rework one day.

Adapting to Change – It's a classic ChangeFailure sitution- the world and our minds simply change too fast for a WikiCommunity? to keep up. No matter how much BarnRaising? you do. Even Meatball, perhaps the most strident about reworking, has a bunch of pages that are out of long sync with it's perpetually developing mindset. This is even with the conservatism that it promotes.

In my notebooks book, I wrote about "the freezing effect" that it caused: Unintentional self-limiting of ideas, or rejection of change. It just happens. It happens on Meatball, it happens here. I think it shows up in WikiSectarianism. You just get conservative when you marry yourself to a document collection and try to maintain it.

It happens to programmers, even. It's called PathDependency? tied to documentation.

Nor does wiki archive well. It's very difficult to "put something into archives." You actually have to go in there, edit the page, and write down: "This is archival. We don't think this way anymore. It's old. Really old."

Categories – Nobody can find anything. Even with search. The world's found a great way for commities to find stuff: Tagging. (AboutTags?.)

If we had tagging, we'd probably find things very quickly. I see no reason to believe otherwise; SocialBookmarking sites are extraordinary successes.

Inflexibility

Integration With Other Mediums. – The RecentChanges page is the portal to the wiki. We do not easily gateway into IRC (WikiAndIrc,) we do not easily integrate SocialBookmarking listings, there are all these things that we have difficulty doing.

That said, we're not too much to blame: Nobody else does this either. (The goal is OneBigSoup, or the DevelopersVirtualWorld.)

Simplicity. – The success of simplicity in wiki has also been it's downfall. We so clearly had it won: You could do the categories thing with backlinks, you could make a little homepage, you could emulate running a blog, you could emulate all these various things.

And then we forget: "Oh, these are just pale imitations of the real thing." Even denying to ourselves that there are very real, very important advantages, found in the real thing.

By wearing "simplicity" as a badge of pride, we have made ourselves inflexible.

If something can't be implemented with just a small deviation to a wiki's source code, we just cast it aside. "Nope. Too complicated. Not going to do it."

We never make any mistakes, but we never get anywhere, either.

(Notice: This may be overly dramatic. Coding software is hard, and going back from a back software change is difficult. Machines are not play-dough, even if they are built out of "pure design & ether," as programs are.)

Original posting

Several heretical thoughts.

What works right:

  • Anybody can come, and be seen.
  • Anybody can edit.
  • Documents.
  • Hyperlinking.
  • Page Construction.
  • SoftSecurity.

What fails miserably in wiki:

  • Reworking. (ReworkingProblems?)
  • Publicizing, Releasing for Public. (ie: publishing to a BlogControlledByWiki)
  • Just letting people talk.
  • Adapting to Change.ChangeFailure
  • Categories.

Inflexibilities:

  • Integrating with Other Mediums. – Then again, no other medium atop the web does this well, either.
  • Simplicity. – The demand for software simplicity has created inflexibility.

Discussion

Then again, maybe the first few that really start reworking let other people set back, so that it's very hard to get more than one or two serious reworking efforts going (on a single RecentChanges)? Perhaps one or two very hard working reworkers will discourage further reworking just as a very hard working founder will deterr other readers from turning into contributors.

I'm not sure about the publicizing part. It seems to work quite well for my homepage. If we used the Blog page as the front page, maybe that would create a different environment.

I agree with wiki being a difficult medium to work with. It is not easy for people to get started, unlike blogs where the comments are an easy stepping stone.

Hm,.. I'm not so sure. That sounds like simplicity speaking again, and I'm shunning him right now, so that I can see what I'm missing; Yes?

On KuroShin?, there are two equivalents to what we would call "RecentChanges."

There's (A) the front page. This is the RecentChanges that most people know and love. On this page, news articles come out about 3 times a week. This is a fairly steady clip; Many webcomics come out at this rate as well.

Then there's (B) the diaries page. (Well, I guess the voting page, as well.)

What's surprising is that people can be reading K5 for a very long time, and not even know that there's a diaries page. And this, (in addition to in comments,) is where people do a lot of their behind-the-scenes gathering and conversing.

It's not exactly hidden, but it doesn't really draw attention to itself either.

Whereas if we just use the blog page, we're still doing so within this framework that exposes all of our "guts." You know: "RecentChanges," "Edit this page," "View other revisions," "Edit near links," etc., etc., etc.,.

I'm thinking: "Gee, there's been a ton of times where we've wanted to publish something, but the mechanism was just too hard."

It's like: The spirit was willing, but the flesh was weak.

Our goal with the machinery, I think, is to make the flesh a slave to the spirit. So there's this whole Devo ethic: "Whip it, into shape, shape it up, get straight, go forward, move ahead" ethic to it.

But we want to do that to the machines, so that we can discipline ourselves in other ways.

I don't know if we have the technical capability to construct something that meets all these concerns with present resources.

Lion, you publish all the time (which is cool), pages vanish in the wiki-djungle when out of the recent changes, but a blog isn't but a page you can read in a browser, just as the wikipages you write on. A real wiki-homepage where we have our section that gets exported automatically in a blog software, for those many who didn't get it yet, k, an idea, but developing the culture to do it, as we can do all of that in wiki, that's another thing. Combining with software that adds to wiki, VoIP, collab-editor, thats alrigt, but do blogs or fora or mailing lists add anything you can't do with a wiki? I don't think so. Long ago I added what's up here to s23-wiki: main page. That was intended in that blog diretion. I never cared about it enough later. wikimatrix-forum: you can't refactor a forum, forget about it is interesting.

I don't mean to convey: "Wiki are bad, blogs are good."

I mean to convey: "Wiki & Blogs are incomplete." And I think we should think critically about what wiki do well. That way, we can say: "This is what we want in a next generation system."

I'm trying to say: Yes. There are things you can do with blogs and mailing lists that you cannot do in wiki. At least not wiki as we envision them today. And the wiki of tomorrow is so different than a wiki today, that it isn't a wiki anymore.

One thing a wiki can't do today: Make a nice rolling presentation for outsiders, voted on by members, without all the affordances of wiki.

KuroShin? can do it. But not wiki.

I think we really need to cram into our heads, the idea that: Affordances = Possibilities.

What is not both automated and afforded, in many cases, is not a possibility!

I mean, look at our summary box, when we commit. In theory, we could have just copied and pasted in the summary line manually, make it a community norm, etc., etc., yes? In theory? Right? But we didn't, except on very rare occasion. We should just shortcut the complexity, and state: "If it's not afforded, it's not possible," to derive the equation: Affordances = Possibilities.

I see two questions, here.

  1. Do we really need the things you mention?
  2. If we do, how do we change community wiki such as to afford what we need?

I'd like to talk a bit about the front-page thing. There's again two possibilities I see:

  1. Mark some pages as "publish on the front-page" while editing them.
  2. Edit the front page and add "include foo" to include page foo.

What do you think? Would that afford easy publishing of interesting stuff on the front page?

More thoughts on what we could do to encourage this:

  1. When aggregating pages for the front page, we'll just publish the stuff up to the first heading or horizontal line, and add a Learn more... link at the end, linking to the rest of the page.
  2. We could disable some of the typical wiki links on the front-page (such as edit, history, etc.)

Then there's the business of change failure. How about this:

  1. How about a conspicuous warning (maybe a yellow box, fading away?) about pages that have not been edited in some time (eg. two months)?
  2. How about a similar warning for pages that have been edited in the last 48h?

To answer the "need" question:

I think wiki doesn't work for outsiders. I'm not interested in aggregating RecentChanges from most wiki. I think that we have things that other people would be interested in, though, and I think we should take part in the larger conversation out there. In that respect: We "need" something like BlogControlledByWiki.

Let's try it then. I'll write a rule <aggregate "foo" "bar" "mu"> that aggregates the names pages in that order up to the first heading or horizontal rule and put an example on FrontPage. If we like it, we'll make it our front page.

Neat!

2 other things:

  • Matching RSS?
  • How about: up to first <h1> heading or <hr>?

That way, we can make use of H2's in our DocumentMode? text, which we do normally, anyways.

On DigestedSummary today I suggested parsing the summary/abstract field as wiki text, emitting the corresponding HTML on the history page, on RC, and in RSS (as CDATA). This allows for an RC and RSS that are inherently more blog-like, and also gives more control over the contents of the abstract. You can use various mechanisms to aggregate. I like Alex's <aggregate>. An alternative is to use some sort of tagging within the abstract in the way that Chris has implemented on MeatBall?. On my own wiki/blog I parse the abstract as wiki text and I aggegate edits that are not flagged as minor edits.

But I'm thinking: "Is that something people want to read?"

I don't think so. No matter how nicely we format our edits, I just don't think people want to read them.

I'm hard pressed to think of an edit that people would want to read.

But the resulting documents, after a first post (that provokes lots of discussion,) or after a bunch of edits: that's something I think people would be interested in, and subscribe to.

This feels great. I imagine the rss-feeds of different blogisizes front-pages aggregated on a wiki-page, the [NearFrontPages? near front pages].

Lion, was you reply addressed at my implementation or at the unsigned alternative? As for the H1 vs. H2 cut-off, there are several points I don't like about it:

  1. I usually never use H1 – the page title is the only H1 there is, all other subtitles are H2.
  2. On other blogs, I'm usually confused by subtitles, because it is never clear enough to me whether the next section is a continuation of the previous section or a new post. Moving all subsections to a separate page would make that distinction clearer.
  3. I think long pages with many subsections might not be of interest to all people, so moving the main bulk of the text out of the RSS feed seems like a good idea.

Oh; I'm sorry– I'm not talking about CommunityWiki.

I'm talking more generally, about wiki as a whole.

I actually never intended for changes to be made to CommunityWiki, or OddMuse, or anything like that.

I really appreciate the changes and efforts to accomodate what I'm saying, but:

(And please don't take this in a bad way, or as a criticism of CommunityWiki): I think we're still talking about putting lipstick on a pig.

Even with all these major efforts, it's still very clear from the FrontPage that this is a wiki, and that the user is playing by wiki rules.

Please don't try to change the wiki to address the thing I'm trying to say! It would be too much work!

A blog has comments, a blog has a calendar for archives, a blog has all these other things that people like in blogs. And it would take enormous changes to a wiki to make it interact like a blog, to even have a section that acts like a blog.

I'm not saying the cool FrontPage work won't work; I'm just saying: It's not what I've held in mind.

That said: The FrontPage may very well work. (We need a little RSS button on it, for the FrontPage alone, so people can subscribe to it.) But I don't know that it will.

Talking with MattisManzel in IRC.

I'm thinking that the most critical piece we need is a GroupServer. That is, the piece that reinvents "RecentChanges." That does the whole "small pieces joined together thing."

I told the story of writing a game ("Infinity") when I was younger. I was adding to it, adding to it, adding to it, in an iterative style. But I ran into this thing where, I realized that no matter how much I added, I was never going to get where I wanted to go. The reason I would never get there, was because it required overwealming architecture changes. In fact, by implementing more and more on my system, I was taking myself further and further away from where I wanted to be, because I was further investing myself in the current system. It was only with a design overhaul that I was able to make the game something else.

I think that wiki is basically played out. I think it's going to get eaten up by competitors, in the near term. The best thing that would happen, is that we migrate to a new platform. The worst thing that could happen, is that we grip tightly to wiki, and gradually fall apart, as CommunityMembers? drift to other things.

One thing that's happened to my interaction habits, is that I've found myself paying more and more attention to UnaLog.

I think a lot of what we do here, on CommunityWiki, is:

  • Share links to interesting things with one another.
  • Organizing the links with one another.
  • Having conversations about the things we see.

Now it happens that, with the exception of the last one, SocialBookmarking does an excellent job of fulfilling these UseCases?. That's because it's made entirely for that purpose.

I have no doubt that we could emulate this activity on CommunityWiki. We could make bookmarklets and submitters and automatic this-and-thats. But, … no! It just gets to be absurd and wacky, after a certain point.

We also do the very bloglike activity of:

  • Sharing big ideas with one another, and then having a discussion about the idea.

Blogs do this great, though.

Granted, you can't refactor them, but damn: If the interface is sweet. And there's a space in the world for archived documents. We need to figure something out.

What we do very little of:

  • Reworking documents, collaborating over a hypertext.

So, back to what I was saying before: I think that wiki is basically played out, as an architecture. Sure, we can implement these nice improvements like AJAX page editing. And it's happening. But I see that as an incremental improvement. It doesn't help us when we want to do SocialBookmarking as a group, it doesn't help us when we want to publish blog entries for outsiders, it doesn't help us get a nice roll of what our members are doing in their personal blogs, etc., etc.,.

I'm leading into the GroupServer. I think that's our natural next focal point. It's point is to pull in WikiAndIrc, to make a nice customizable centre-point, to collect all members' personal blogs like a Planet, to show recent document edits, to show status displays for whatever, etc., etc., etc.,. Yadda yadda yadda. Small pieces joined loosely, or whatever the phrase is.

BulletSummaryBlock for "Conversation with Mattis in IRC:"

  • GroupServer is most important: Small pieces joined together.
  • Story of "Infinity" – kept making incremental changes, but redesign required to go forward
  • Wiki is played out.
  • We can adapt or play Amish.
  • Activities on CW:
    • Sharing links, organizing links. – SocialBookmarking
    • Big idea, let's talk about it. – Blogging
    • Collaboratively make hypertext. We do that some times.
  • A GroupServer could integrate: SocialBookmarking, wiki activity, blogging, WikiAndIrc, nice presentation, etc.

I'm not convinced of this social bookmarking thing. I was never curious enough to try it, and the few times I looked at it, I was not excited at all. I am subscribed to the bookmark feeds of some friends, but I'm much more interested in their blog.

I also think that wiki works fine for a blog. I like my blog, for example. ;)

Now, it's true that on a wiki, there's a lot more reworking of existing pages. Pages are in flux. But then again, I know that I can edit any page on my blog, and so I do. The architecture affords editing and a pure blog does not. So the effect is that RSS feeds for wikis are a bit of a mess. I agree with that. But does that mean that wikis are bad for publishing? That feeds don't go together with wikis? Or that blogs are superior for publishing? Not at all! It just means that RSS feed consumers – the aggregators and clients people use to follow conversations on the web – are not yet advanced enough. They can't handle it, because the interface is bad. But there are a gazillion ways of improving the interface! It just needs more time, more thought, engineering and ideas. It will come.

What I absolutely oppose is dumbing wiki down just because other people use lousy software to read our RSS feeds. We're at the forefront, exploring the possiblities and the user interfaces that we need, because they don't exist yet. We don't want crappy feed readers because the end result is that they cast feeds into the very same format that mailing lists and usenet use, except now we have even less expressive power, even less freedom! That's sad. That's depressing. That's regressive. I want no part in it! Let's improve feed aggregators. Or lets remix our feeds so that poor clients can get a decent picture of what's going down on our wiki.

I also find that reworking happens a lot on Emacs Wiki and on Oddmuse Wiki. It doesn't work here because there's you, and there's Mattis, and there's little pictures with our faces, so we set the stage for a conversational medium. That's ok. It also means we have little reworking. And that's ok, too. Community Wiki is not the only wiki. Every wiki is different. Every community is different, too.

And wiki does wonders when we don't want to share (broadcast) an idea but organize it. Help put all these tiny fragments of thought together, and build the building blocks that we need to express larger ideas. We're standing on the shoulders of wiki when we talk. If we had a blog instead of a wiki, it would not have worked. Blogs don't provide a LinkLanguage. Blogs are one-way in many more ways than wiki is.

Finally, I'm really interested in trying things out with wiki. Being a coder, I believe it to be very flexible. So I don't really understand why you are ruling out incremental changes.

Seems to me like you've somehow lost faith in what we have written on these pages. I wonder what changed your mind.

Let me list your points down, for answering:

  • Unconvinced of social bookmarking. (Not curious, not exciting. Subscribed to some feeds, but blog more interesting.)
  • Wiki works fine for blog.
  • Blog doesn't afford rewriting, wiki does.
  • Are wiki bad for publishing? (No.)
  • Do feeds not work with wiki? (No.)
    • Need better aggregators.
  • Are blogs superior for publishing? (No.)
  • Oppose dumbing down wiki. Lion: I'm not sure what the defence is against – what aspect of wiki is threatened with dumbing down?
  • Reworking happens a lot on Emacs Wiki, Oddmuse Wiki. This wiki is just more conversational.
  • Wiki does well when we organize an idea: Put framgents together, and make a larger thing in summary.
  • Blogs do not assemble ideas. (No LinkLanguage, no reworking, …)
  • Interested in trying things out; Why rule out incremental change?
  • "What's changed your mind?"

Excellent points, and fair questions. I think this will help make clearer what I mean to say.

Quick responses:

  • What changed my mind: Reading blogs, wanting to say things, sharing links, sharing files, comparing our shared link lists (SocialBookmarkingToWiki) with other categories, thinking about ChangeFailure, reading RSS feeds, interacting by voice, interacting in person, yadda yadda yadda.
  • The value of Social Bookmarking, for us, as a group, comes in when we look at things like our visualization technique categorization pages.
  • Blogs are better than Wiki for publishing something like a newsletter. And: They can be edited in the future, though you only use that for spelling, grammar fixes, minor updates, and pointing to related resources.
  • The argument about the presentation of RecentChanges misses the more important point: Internal cross-chatter, vs. public following.
  • I'm totally with you on: We shouldn't dumb down wiki.
  • I overspoke: Wiki works awesome for Oddmuse wiki, and the Emacs wiki. Documentation and support communities do great with wiki – much better than blogs.
  • Organizing ideas: Quite a quandry! We need to think about this. Organized ideas are better than unorganized ideas, but what about ChangeFailure? Perhaps blogs can gain LinkLanguagePlainLink? An idea in tension.

So, here's what changed my mind:

  • I see the ease of sharing links with people over on UnaLog. I actually do read the links that other people suggest, and I am frequently pleasantly surprised by what I find. There is a difference between UnaLog and DelIcioUs?, because UnaLog is a small community of related people. Aside from the WW2 guy, that is. We tend to pick up on each other's links. Here on CW, we generally have to write a whole page to share a link, or spend time finding the right place to put it. Most of the time, I just don't even bother, because it will take so long. I want it to take 5-10 seconds from seeing a link, and sharing it with CommunityWiki.
  • Tagging works spectacularly well. I can find every single link I put into UnaLog. But I have a very hard time finding things on CommunityWiki, even with our Category system. It takes far less time for me to put something into UnaLog, and it takes me far less time to find it. Our category system, here, takes forever, though! And it's usually out of sync with our PageDatabase?. If we themed a UnaLog for CommunityWiki, and somehow duct taped the systems together, we could just tag our own pages with it.
  • Conversations & Blogs. It's spoiled me. There's just so much out there. And it's a conversation. When we write on CommunityWiki, we focus towards the DocumentMode? and community consensus. I'm still trying to figure out how to articulate it, but I think it has to do with the image of WikiSectarianism. When someone writes a response in a blog: "I don't think so, I'm not so sure," it's not seen as a voice to be included in a future DocumentMode? version, or something like that. Rather, it's a comment on an article, and is preserved as a comment on an article. It doesn't need to be reworked into the page. I need to think about how to think about and explain this idea clearly, but there's something there– I'm confident of it. There is some aspect of wiki that is not sociable..!

Uh, well: I have more to say, but have to go right now. I'll be back near the end of a Seattle day.

Feel free to respond; Don't wait until I get back.

Three lines for the extended subtitle / page summary, like it is, when the three lines are full you can not add more text.
Then one empty line.
Two lines for the news, like we already do it: + message. When you add at the end and the two lines are full text vanishes at the beginning, rough, fast.

Both section make the beginning of a page, tagged.

The first, the subtile/summary slowly gets refined and moderately fast adapts to new aspects on the page. The news part reflects news, but dirty.

You see these two sections for every page on the recent changes and they make a core information sent by our rss feeds. A selection of them makes the lower, the blogisized part of our front page.
Both new readers understand, and involved community members get the fine movements right from the recent changes/rss-feed/front page.

Lion, I'm note sure you whether you are interested in hearing about possible incremental changes to solve your problems. I fear this is not quite the response you want to hear. You are on your way out, looking at the spaces ahead of you, where as I am rooted into the ground I stand on. You want to abandon the sinking ship, and I want to grow and extend the amazing fortress. Yes, in my hands wiki would continue to evolve slowly, but I guess I look at code such as Emacs, started as some hacks with one of the first editors, or I look at Apache, code that built upon the very first webserver there was.

Anyway, what I really care about is splicing RecentChanges so that the result is a decent feed, fixing CommentPage?s so that they really fit the bill, examine the various tagging extensions that exist and finding the right feature set that is easy to understand, easy to understand, and easy to code up, how to link tag-based searches with indexed search, etc.

If small incremental changes would solve the problems, I'd love to see them.

But I don't think that they do.

And, again: I think that no matter how nice we make a RecentChanges feed look, (which would be nice: nicer is always nice--) it's still going to be Recent Changes. It's not going to be a publication feed, it's not going to be a stream of completed documents, etc., etc.,.

I'm not telling you to do something other than what you're already doing: When I write a Criticism of wiki, I'm not requesting action from anybody. (And I'm not saying: "I'm leaving CommunityWiki!" either..!)

I am doing just what I said: Criticising wiki. I want to clearly understand the space it fills, and I want to clearly understand it's limits. What types of interactions work on wiki, and what types of interctions don't work on wiki.

I don't think that wiki is a "universal platform." Anyone could, of course, with enough force, make it into a universal platform. But that's true for anything. It would basically not be wiki any more, by the time it was universalized.

I don't understand the part about "not forming a real community."

I sure feel like this is a community.

And if we're somehow not a community, I don't see how that's a criticism of wiki; The same could be said for blogs, IRC, whatever.

To add to the critisism in my opinion wikis have problems with forgetting. In all other systems older stuff goes somewhere to the archives where it is not really hidden, but does not clutter the current area of focus of attention. In wikis everything stays forever - thus we need to manually restructure the pages to delete the older cruft. But this will never be efficient enough since first it is difficult and timeconsuming, second it is much more difficult socially to delete something that was written by someone else than to add something new. In my opinion what is needed is a dual wiki-forum system where on the wiki pages users could keep the most timeless information and have a forum to discuss things, to express opinions of only temporary value. Of course tings and IRC and IM chats can be as well used for discussions. Observe how in IRC and chat the rule of forgetting older stuff is even more absolute than in fora.

Another point, the communal owhership of pages creates another social barriere - no one feels responsible for the refactoring. I would propose to experiment with some kind of personal ownership of pages, this does not need to be strict and technically enforced, we can start with just some customs. For the owner it would be much easier to delete or move to other pages snippets that don't add to value of the page.

Such hybrids have not been successful, up to now. It's complicated for users to choose the place according to the value of what they are writing. They probably prefer whatever they are used to or pick first.

In my opinion this is just a problem of "use culture". One could try to delete old discusssions and to ask everybody to add what he has learned to the document section. What is not remebered should maybee be forgotten. Technology could help by providing a "start new version" action, which replace the discussions with a list of involved people. Try ReCreation? in favor to remembering.

Perhaps we need some feature that reminds us of age. For example, "old" articles could be paler, or there could be a warning message, etc. MeatballWiki? embraces the WikiNow and removed the timestamp at the bottom of pages. As an experiment, we could go the other way and embrace timestamps, or at least age proxies. Unfortunately wiki pages don't have coffee spots and wrinkles, but we could add them via CSS to old pages. ;)

I would particularly interested in "going the other way" with Timestamps. While I really do appreciate the objective of "timeless prose", there are just far too many situations in which (as lawyers and bankers say) "Time is of the essence."

By the way, I think "coffee spots and wrinkles" may be the wrong indicator. How about emulating real pages that turn deeped shades of yellow with age? Or (a more personal observation) having had dark brown hair once upon a time, I appreciate the "salt& peper" look that was replaced with "silver threads" and is now best described as a "grey beard & thatch". ;)

Not much to add other than to say I'm enjoying following along on this discussion. I find the criticisms VERY important. Excellent work, Lion. What makes Wikipedia work? Is it software? Is it culture? NPOV?

I threw out: Formation of real community. – Over time we know and like each other but that doesn't really make us a community.

It's not a wiki issue, that's just an Internet thing.


CategoryWhyWiki

Define external redirect: WikiPediaIsNotTypical AboutTags MeatballWiki NearFrontPages WikiCommunity CommunityMembers KuroShin ReCreation PageDatabase DelIcioUs ReworkingProblems DocumentMode CommentPage BarnRaising MeatBall SlashDot UseCases DeepDisagreements PathDependency

Languages:
https://communitywiki.org/wiki/CriticismOfWiki
communitywiki.org
crawl=CC-MAIN-2016-30
64452
application/http; msgtype=response
sha1:L7Z6VDEUNFWC66IS2AJNPDQPRHVSXNFE
<urn:uuid:a9bf8b34-6020-4d28-96ec-5331661dd289>
2016-07-29T03:57:22Z
192.71.233.105
sha1:V4TWGGUS4KND5NRMMLXIKQQLO4JRUUQO
<urn:uuid:0ba8a1c8-1120-40eb-8b3b-694103108cd3>
https://communitywiki.org/wiki/CriticismOfWiki
length
response
<urn:uuid:a0c648ab-defb-419e-9fac-93012ae2b72c>
robots: classic
hostname: ip-10-185-27-174.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2016-30
operator: CommonCrawl Admin
description: Wide crawl of the web for July 2016
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf