WebDB Item

TC Administrator

This item is part of the public WebDB named TC Administrator - Add Feedback

CommunityWiki LackOfReworking

24/12/2006 - 15:22:57

LackOfReworking notes:

Reworking is rewriting the text for future readers. summarizing, drawing lessons, clarifying.

Page states "rewards for the person reworkign are minimal". Although, I would make a small argument that rewards are the same as the rewards for the person that jots down notes and summarizes key points from conversations. So, the rewards are enhancing your understanding.

ThomasKalka: 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

Lion mentions taking notes while reading. I try this out here. (I could also try out in emacs, which would allow me to also try ZergCreep) “CommentGranger?” or a “WikiGranger?.” That is what I am doing with this post to my WebDB, which I am typing in a small window that comes up when I click on a bookmarklet in my browser.

Lion also explains why technology is a bigger factor in LackOfReworking than social issues.

Huge contribution by Lion, see his BulletedSummaryBlocks on the page.

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.

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.

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

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.

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.

Lion:

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.

ThomasKalka: LackOfGranularity seems to be the main problem. So SupportGranularityInWiki.

BillSeitz: 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.

AlexSchroeder: 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. he 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.

Lion: 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.

Mattis: 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.

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

AlexSchroeder: I like to read web pages that have key points in bold.

Zby: 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.

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

Zby:

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.

Keith: 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:

the awkward position of deleting everyone else’s comments
the perceived confusion that may occur when thread participants return to the discussion only to find it has disappeared.

Sam's notes:

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?

(and/or)

* How do we change the technology to let the machines do the work for us?

Original Location: http://www.communitywiki.org/en/LackOfReworking

Drill Down Search: cwnotes virtualcommunity tctheory wiki writing learning lackofreworking Keywords: cwnotes virtualcommunity tctheory wiki writing learning lackofreworking