Discussion-mode inside wiki pages seem to be mis-use to me. DenotingAuthors like we do with the ![new:ThomasKalka:2005-12-22 19:31 UTC] notation is the wrong way. Comments are atomic, have a date and an author. Just allow these as seperate, nested micro-content, for wiki-pages also. benefits:

  • it would be easier to add comments
  • more magic would be possible like
    • aging of entries
    • tagging of entries
    • transparent way of hiding / digging into past

what kind of technical support would i like to have for reworking

  • an easy way to tag discussions on a sub-atom level
  • an easy way of marking discussions as “reworked” → point taken and noted somewhere
  • something like refactoring

this is more poetic than rational up to now, feel free to comment nonetheless

When I’m reading something someone’s written, I’m frequently taking little notes, running “notepad.exe” or a vi or EMACS buffer, listing the points they’ve made.

It would be interesting (but likely expensive to make,) and potentially very powerful, if we could annotate people’s comments with “key points.” Perhaps we should call this idea a “CommentGranger?” or a “WikiGranger?.”

It would have to be very easy to do, and unobtrusive.

Then, when you go to refactor the page, you don’t have to reread the whole page. You can just go through the key points that people have identified, in the granger, and summarize based on what you remember in your head.

That’s one way we could encourage refactoring: By making it easier to do.

The system would have to be set up to afford the use of the granger.

People’s comments would occupy the left 60% of the page. The right 40% is reserved for the granger.

To add to the granger, you click into it, and type a short phrase. That becomes a key phrase.

It’s “wiki,” in that you can edit it, and it applies linking mechanisms, italic, bold, and what not.

I would add here the social awkwardness of deleting other user’s additions. It is like silencing them or destroing their contribution: “Thank you we don’t really need your comment”.

to encourage refactoring I would make a two line summary in the recent changes and the core of our rss-feed, digested changes. To make a good two line summary you have to refactor the page.

I disagree very strongly (and with some anger) with the notion that it’s just our “social problem.”

That reworking is something that we “just need to get in the habit of.”

I disagree very strongly with the line: “Reworking is a new art and only a few people really seem to master it, if at all.”

Balogna. I know how to rework. Everyone here knows how to rework. Reworking isn’t hard, as in “we don’t have the mad Skillz.” There may be an “art form” to it, but everyone likes to see something that’s been reworked even just a little itty bitty bit, by someone of basic capabilities.

No. The simple problem is: We don’t do it.

Oh, I disagree so strongly with MeatballWiki:ReworkingProblems..! And my number one reason for “why refactorings are rare”..?

Because it’s simply not high enough priority. At the end of the day, you have a choice between:

  • (A) talking about something that’s important to you, and immediately relevant to current context, or
  • (B) reworking some old document on the XML-RPC vs. SOAP battles of yore.

Where yore = a few months or years ago. ChangeFailure happens because the world changes faster than our wiki’s documents do, and ChangeFailure is exactly the problem with reworking.

I will grant that if we turbo-boost ourselves with some hi-tech reworking technology, we can make some changes that can get us to the reworking Haranya Loka that may well be possible. And we can use some more hi-tech technology to cut ourselves off from dead weight: By throwing pages into virtual archives, and what not.

What’s going to get us forward here is computers, computers, people, and computers. And I beg you in 15 years to try and prove me wrong without laughing.

Linux can’t be made by shipping CD’s back and forth across the country. You have to have an Internet.

The argument that Linux could have been written by shipping CD’s back and forth across the country because it is possible to burn CDs and put them into envelopes to get them to a destination is missing something.

The argument that we can do lots of refactoring and still be relevant and not stuck in the past without “high wiki technology,” but rather on the back of self-imposed slavery, is a bogus one.

Town encyclopediaists of the distant past may have whipped themselves in the back with cat-o-nine-tails for not being persistant or strong enough to try to gather, edit, and copy encyclopedias by hand for everybody, but we’re not going to make that mistake. We’re going to invent computer chips instead.

It’s a failure of wiki.


  • It’s not a social problem.
  • It’s technology.
  • Everyone knows how to rework.
  • Reworking is expensive.
  • Reworking is not high enough priority.
  • We need computers, computers, people, and computers.

Let’s do some critical thinking here: Why is it that you can’t make Linux by shipping CD’s back and forth across the country?

  • The communication paths are there, after all. (Computer source code & discussion) -→ CD-ROM -→ letter -→ CD-ROM -→ Computer source code.

But the problem is that it takes so long to send your messages back and forth. Your latency is so high.

The reward is less time in the coming.

And the number of people for whom the process is high enough a priority drops to near zero.

Thus, no Linux.

The critical factors then seem to be:

  • The priorities held by the people who can be engaged in the process.
  • The power (energy or force applied over time) of the technology.

The technology does not refer to the Linux source code, in this example. The technology refers to the communications path, in this example: The guy burning the source code to the CD, and then writing up an envelope, and then mailing it to the other guy, who pulls it out, and installs the source, and reads the discussion, and continues working on it.

Because very little messaging and very few interactions can happen per unit time, we hit the second major barrier: Priority.

There are so many “all or nothing” scenarios, where you’ve got this gigantic step in the curve. And it happens when something strikes against someone’s priorities. We’ve all experienced: “I would have done such-and-such, but it just simply wasn’t high enough priority.”

And did “just a little bit get done?” Do we attend to everything with some degree of attention? There are things that scale by degrees, but there’s a lot of them that hit the “anything or nothing” quanta, and there we are. It’s the whole “SmallChangesYieldGreatChanges” thing.

Helmut, I respect you, I’m always so grateful for your presence here, I value your perspective, I am sending little hearts with feathery wings to you in my mind right now. You’re awesome.

But I just think you’re dead wrong on this one. :)


  • Why can’t you make Linux, just shipping CDs?
  • Too few interactions per unit time.
  • Which means too little reward.
  • Which means deflection off the priority stack.
  • SmallChangesYieldGreatChanges.

If we’re truely serious about reworking, then I would think that we should think, from a technical level: “How can we change wiki UserInterface so that it makes reworking easier.”

We’ve heard many ideas. And I’m sure that we can have many more ideas.

I would move to transition the discussion to these sorts of questions:

  • What ideas do we have about how to make wiki afford reworking?
  • What UserInterface changes would make it easier to rework, once you’ve decided to?
  • “What is reworking?” When we rework, what exactly is it that we’re doing?
  • Where is the time spent in reworking? I’m talking Therblig type analysis, here. Motion study. Old skool. Like in the book, not the movie. (see: Gilbreth) 1

Implementation Questions:

  • What is the HiveMind going to implement?
  • What can the GreaterWikiCommunity? implement?
  • What is AlexSchroeder capable of implementing?


  • We should analyze reworking technology.
  • How does reworking work?
  • How can we make it cheaper?
  • What can we implement?

Here’s my immediate thoughts on what reworking is, or how to rework ThreadMode into at least a summary, which would be a good starting point, no?

  • (1) For each comment:
    • (1A) Read the comment. Note who is the commenter, and what major new ideas come out of it.
    • (1B) Write author & keywords down.
  • (2) Look at the collection of keywords, which represent the ideas.
  • (3) Write the ideas plainly and succinctly, in summary form.

Some people may think that writing is the hard part. “We just don’t know how to write.” That it’s step #3. I disagree very strongly.

It’s not the last step that’s the problem.

It’s step 1A! It’s all the mountains, and mountains, and mountains of reading that has to be done. Good lord, and it’s energy consuming. I mean it’s just dreadfully boring, to read and reread and reread something that you’ve already read before. Good lord is it boring.

So, I would think that if anything, we should do what we can to destroy step 1A.

And I mean: That was the whole point of BulletSummaryBlocks?. And every time that I’ve used them, and went back to rework something, those bullet summary blocks: I’ve been so grateful for them. They work so well. It takes far less time to go through the block, than it does to reread everything, all over again, scanning for ideas.

That’s what leads me to think that the WikiGranger? may be a good idea. Take the right hand side of the page, and make it the granger. Perhaps for every paragraph, we align the right side with the left. And make it auto-editable, the stuff on the right. You don’t have to hit “edit this page” to get to it; You just put your mouse over on the right hand side, and start putting in keywords that note the major ideas.

That might be a start, that might help.

That way, after the discussion’s over, you just go down the right hand side, and you strip off all the keywords. From there, you can very easily re-activate the whole conversation in your mind, without actually re-reading it, and you can trust yourself to write a fair summary of the discussion, or perhaps to a full page rewrite or whatever.

This is the sort of thing I can help.

But I suspect that this grates on simplicity; Right, Alex?

I know that we can’t implement everything we dream of. I know that there might be little point in imagining features that we can’t cheaply implement. I can imagine how irritating it must be to hear fantastically impossible things, such as the DevelopersVirtualWorld, that we can’t possibly ourselves implement here. (We’ll do it, but it’s going to take a civilization’s efforts.)

But we must seriously not kid ourselves about what our present technology (or technology in near reach) can do, either.

If I had to name a technology that I think is within reach, that could make a profound difference, I would name an SVG wiki as it. Another is MachineCodeBlocks: When programmers are casually pulling somewhat structured data from wiki, (and by that, I mean: “structured beyond just HTML and page contents,”) that’ll enable a whole buch of stuff as well.

The summary box reworking stuff has been within reach, and, despite what I interpret to be Alex’s disinterest, I think it was a really awesome change, and I never want to go back. But it is a relatively small change.

Changing how we do reworking would, I think, have to be big. But we should probably brainstorm it, if we’re actually serious about this. We should, if we’re serious, and if we accept that this is a technology problem and not a “oh, we just need to whip ourselves some more so that we rework our documents some more” problem, then I would think that our next step would be to spend a few days brainstorming for reworking technologies.

There might be something, very close by (in “implementation space,”) that Alex can make use of, to make things much more easy to rework.

So, I guess my major thoughts here are:

  • Study what reworking is, what the expenses are,
  • brainstorm for features,
  • see what’s near-term implementable by Alex.


  • How does reworking happen?
    • Read comments.
    • Note major ideas.
    • Write a summary.
  • Reading comments & noting the major ideas is very costly.
  • Which suggests: WikiGranger?.
  • We can’t implement everything. But we shouldn’t kid ourselves about our limitations.
  • SVG wiki, MachineCodeBlocks: in reach, likely major effects. (But not reworking.)
  • Lion thinks: If interested, we should: study reworking & brainstorm “easy” features.

ThomasKalka, if my interpretation is right, I’m right there with you. I totally agree with you. I’ve agreed with you for years, and have the timestamps to prove it!

  • Comments should be modeled differently than documents.
  • We can find ways to make threads reworkable, despite comment protections and special treatments of comments.
  • We should totally be tagging our pages, (making them easier to find, making them easier, in turn, to link to and reuse,) and we should totally be able to tag individual comments, even.

We need to, as a community, I think: Smash the ideal of simplicity.

When the ideal of simplicity serves us, as it did with the birth of wiki, it is a great thing. But that ideal is not serving us any more. Instead, it is controlling us.

Alex: I understand that it takes time to implement stuff, and maintain stuff. And I understand, as a fellow programmer, programming since I was 7 in BASICA, programming in Pascal when I was 10, picking up C and C++ when I was 11, and speaking and writing and reading in countless programming languages- I know what a great thing simplicity is. But there’s the whole Einstein thing of: “As simple as possible, but no simpler.”

I think that the basic wiki format is pretty well played out. There are things we can add, like MachineCodeBlocks, or emailing to wiki pages, and stuff like that, that make incremental improvements to the basic form, and strengthen the fortress.

But I think that if we’re going to get around these “hard problems of wiki,” that we have to make a major reconceptualization of what we’re doing, and how the data is modelled in the back end.

If those changes are impossible for us to implement, because of the nature of where technology is at right now, and how much time we have, that’s okay. We don’t have to do the ultimate. But we should at least know what we want, and why we want it, and how are problems are reduced to it, even if we can’t implement it.

What I mean is, in practical terms: If reworking truely is a technical problem, (not a social problem,) and if answering that technical problem truely is hard, and out of our reach, then we should at least know those things.

That way, at least, we won’t waste more effort in “ouch, ouch, I’m whipping myself because our wiki isn’t reworked, ouch, ouch.” And when people ask: “what are you doing to fix it,” we can say, “This is a problem we know about. We are making these small changes X, Y, and Z, which can help a little. But to really solve the problem, we think FOO. And FOO is hard because of BAR.” Where BAR is some hard technology sub-problem.

Then we can point people to FOO and BAR, and people can work hard on FOO or BAR, if they’re interested.

But at least we’ll be done with that conversation.

I’f we do not find something easy to support reworking, we do not understand the problem.

LackOfGranularity seems to be the main problem. So SupportGranularityInWiki.

I’ll take a different tack on this, without tact. (I try not to repeat this rant too often, but I can’t help it.) ReWork?/ReFactor? is a process of Convergence. But with different minds just spitting ideas around, Convergence seems unlikely regardless of technology. Perhaps this belief is counter to HiveMind. When discussions are about abstract ideas not intended to lead toward short-term WebSeitzWiki:DAndD, then it’s hard to evaluate whether a ReWork? has improved clarity (or any other metric of good-ness), and at what cost. I think the TeamWiki? medium is great for doing DAndD? work. I think the PublicWiki? is less effective as an undirected conversation space. But that’s just my spin…

Actually this is something I agree with. I think on Community Wiki we have a lot of explorative or philosophical pages. They are subjective and tentative by their very nature. There’s very little refining to do, unless you agree with the basic idea. Other than that, you can discuss: Disagree, disagree with points, offer additional data points, links, etc. For that kind of interaction, our system works very well. It’s a good mix of wiki and forum style.

And for those pages where some people share interests and want to invest enough energy, we do see reworking. And I don’t think we’re doing too badly, either. I remember that the big reworking efforts on MeatballWiki were also the work of a single dedicated individual that would rework a set of a dozen pages or more. It happened every few months! It was never a common thing.

And I also agree with Lion that sometimes the benefit of reworking is too small -- I'd rather work on something new!

So basically I think our current format doesn’t require a lot of reworking.

I think Alex is basically right: Our current format does not require reworking.

That said, it would be nice to get summaries of our conversations. Reworking is not necessarily about converging on opinions; A simple “conversation highlights” would be interesting, a convergence on what was said and notable being all the necessary convergence that’s needed, then.

Or, perhaps, we should take a leaf from the person who mentioned page ownership, (I can’t quickly find the text on this page?), but instead of making page ownership, make it so that we all have a section at the top of the page where we summarize our personal position.

That way, we never fear that we are messing up someone else’s text, but we do get a reworking, of sorts. That might work. We don’t have to reread all our text; We just make sure it’s consistant with our own thoughts in our own head. That eliminates a lot of the time involved in performing a reworking.

Whatever probably takes a community closer to the point to be able to write a good three line summary of a page, reacting fastly on developements of a path of thoughts (summary on recent changes and in the rss-feed) is good.

Lion, basically I agree with you criticism of my position, which seems a way of old-fashioned or stereotypical to me now. It’s old-fashioned because people like to answer “something isn’t done” with “ok, that’s because it’s hard to do”. Just as people are kind to each other and promise help, but just “have no time” afterwards. Your “people are just not interested” is much more to the point, although I’m not used to cw being so socially direct. This talk about “art of reworking” is definitely bullshit, although there probably is soem kind of craftsmanship in it and although we know that some people do it extremely well (Alex for example) and others won’t and I don’t see how you can say “everybody can” if we are in the situation that “nobody does”. It’s a bit like “everyone can sing” . that true, but the quality of singing is not always inviting to listening. But that’s not the key point. You are right. Period.

Wikis do not give much technical support for reworking and it is makes sense to think about TechnicalSupportForReworking.

With respect to the pages and content you dislike, why don’t you comment or change them?

Personally I like to read web pages that have key points in bold. If there were a community convention to support it, maybe we could all start writing like that.

Or we could have some other markup to provide a different background as if using markers. The people from 37signals use that to highlight their text.

Plus, JakobNielsen still recomends using bold to highlight key phrases on web pages.

I don’t agree with Lion that it is so obvious how to rework pages. First of all I am not sure how much you can compress a conversation before you lose something from it, see Conversational writing kicks formal writing's ass.

I love that article, I’ve forwarded to to a zillion people, and I believe even linked to it here. You remember that I wrote PlainTalk here, right?

I have absolutely zero idea how that great article refutes what I’m saying here.

The point of compressing conversations is “to lose something.”

If something is occasionally lost that is important, even, that’s okay too. If it’s truely important, someone will notice it, and put it back themselves.

First of all we should think about what we want to have here. What kind of pages - for what purpose. I can see two purposes of the communication here:

  • conversation - content that has a meaning mostly in the context when it was created, it has only marginal value after a longer time, it is also cheap to start from the beginning
  • refference - pages that we can link to from outside of CommunityWiki, should be in DocumentMode, not excessively long, a definition or a clear thesis.

In this perspective I do agree with Thomas that we need a forum for the conversation part and only use wiki for the refference with easy interlinking and attaching of conversations to documents.

As a fan of design’s role in problem-solving, I believe there is an affordance for everything (WhatIsAffordance)! I have considered this problem of LackOfReworking, and tried to design a widget that encourages reworking.

There are several barriers to reworking. Some of which may be addressed easily. One is the awkward position of deleting everyone else’s comments. Another is the perceived confusion that may occur when thread participants return to the discussion only to find it has disappeared.

One way to deal with this is to give the reworker a visual page place-mark that acts like a historical marker. Where I live (in MeatSpace), there are thousands of these little markers everywhere, reminding us of what happened on this spot in 1776 or what used to stand here or some battle, catastrophe or whatever. I’m essentially proposing the same type of thing, where the reworker acts as historian, marking that the content has been reworked, possibly moved (and to where), who participated (giving credit), and when this all happened (to look in page history).

The reworking icon should be visually unobtrusive, functional across stylesheets, and hiding additional information inside the alt-tag of the image. Since reworking markers provide little value to new page visitors, perhaps they are eventually moved to the reworker’s NamePage as a badge of honor. Reworking is hard work after all!

The concept was introduced on 2006-12-16 and can be seen at the top of the comments section here and an alternative approach linking to CommunityWikiGovernmentMotivation here.

(Keith, your visual cue icon idea is a good one!).

The thing that drew me to wikis intitially was the potential to use the tool to synthesize knowledge.

I think, after reading this page and taking quick notes on it, that the LackOfReworking problem is both a technical (Lion), and a social problem(Helmut). (“It’s a floor wax!”, “It’s a dessert topping!”, you’re both right!).

LackOfReworking is a techno-social problem. A set of problems that stems from the way that we collectively solve problems through technological mediums.

We desire more ordered DocumentMode pages for future readers and future reference.

Yet, in the more immediate, closer-to-bounded present, we function and flow more loosely in a conversational pattern.

We use wiki technology here as a techno-social attempt to weave together the past, present and future.

The CommunityWiki HiveMind is close to creating a sustainable techno-social system here for doing this past/present/future weaving. LackOfReworking can mean a LackOfWorking? in the present for the future. Why should you have to re-work? (I know that these points have already been made in different ways by others). You are already working. DoItOnce?. DoItOnce? to weave together the past, the present, and the future, and be doen with it.

So, my contribution to LackOfReworking is:

  • How do we DoItOnce? within the bounds of the current technology? (some ideas are already presented in this discussion, BulletSummaryBlock, notetaking when reading.)


  • How do we change the technology to let the machines do the work for us? (many ideas in this discussion for technological changes).

(I tried LionKimbro’s method of taking notes while reading. My conclusion: it really helps. here are my offsite notes on this page LackOfReworking summary)

Well, remember: I’ve had a complete 180 in my focus.

Above, I wrote that it is a technology problem, and requires a TechnologySolution (TechnicalSupportForReworking) 2006-12-21. But in ConversationProcess, 2006-11-12, I made a complete 180, to CommunitySolution, specifically, the BenevolentDictatorProcess?.

Basically, assign a person who’s in charge of reworking. That person is then tasked (“Who will do it?”) and entrusted (“How do I know it’s okay?”) and credited (“How do we thank them?”) with the work. If the person who does it is the person who cares most about the subject, and if the reworking is done on a continuous blow-by-blow basis, then most of the objections under “Hard” can be met.

That’s my theory. I believe it has, and will, stand up to test.

BayleShanks reworking the CommunityWikiGovernment pages is an example. HelmutLeitner & I’s work on SourceOfEthics is an example. There are some minor examples as well, such as the structuring of the page ConversationProcess as well.

I personally feel that the solution has been found here, and that we just need to realize that we’ve found it. The empirical evidence is in. I think our difficulty in seeing it is in that we are attached to NoLeader, which is the basis behind the TraditionalConversationProcess.

I think we can respect NoLeader in other ways. But I don’t think this is the place for it, where clear leadership clearly works.

I don’t mean to subtract from the good technical ideas here, though. I have a hard time seeing a granger as a bad thing. DiiGo may be a perfect thing to use for the granger service, at the very least to try out the idea. (Make one account, for the entire community?) Because the granger is throw-away, I’m not so concerned with data lock-in / proprietary.

I do think that “DoItOnce?” is a great principle to identify. I think that having one person who is in charge of maintaining the page basically keeps with the DoItOnce? spirit, especially if the maintainer is working continuously on working on integrating content and ideas. (This is also a method of doing the work incrementally.)

“Why do we care about reworking?” We didn’t answer that on this page, anywhere.

It seems obvious: “So that we can reread it again later, and not have to piece it all together. And so that outsiders can read it, and learn it.” Yes. But why? “Because we think that our conversations actually have interesting results, and we want to help people (including our later selves!) more quickly get to those results.

That is, to get the fruit of our conversations, and to distribute that fruit widely.

Some things are only transient, and we don’t worry about those things. But if we find most of our things are transient, then we’re probably wasting our energy. So some of our things should be something more than transient, and those things we want to see reworked, so that we can share the fruit of its value.

Okay, so it is obvious. But I just feel that that question, and that answer, should be articulated on this page somewhere. We may get around to reworking this page at some point. ;)


1. Lion, commenting on “Cheaper by the Dozen,” the movie: “Oh, God; What a sad, sad, sad day it is for the Gilbreths.”

Define external redirect: WikiGranger DoItOnce ReFactor CommentGranger BenevolentDictatorProcess DAndD GreaterWikiCommunity BulletSummaryBlocks LackOfWorking ReWork TeamWiki PublicWiki

EditNearLinks: CommunitySolution DiiGo MeatSpace MeatballWiki JakobNielsen UserInterface DocumentMode