LackOfReworking

Reworking (see: WhatIsReworking, MeatBall:CategoryReworking) in the context of wikis is the editing of a page or of a group of pages such as to rewrite discussions and comments in a more compact form. The key aspect is that you are rewriting the text for future readers: Drawing lessons, removing or clarifying references to events no longer current, providing a summary near the top, introducing main ideas before delving into details, etc.

It doesn't happen often. It takes time and energy (ReworkingEconomy.) People don’t like to rework. It’s laborious, rewards for the person doing the work are minimal. See ReworkingProblems.

Plus the time and energy could be invested in something new instead of cleaning up something old. If pages are subjective, or their importance transient, then it doesn’t make sense to invest time and energy in them (ReworkLazily.)

This page started out as one of the points on CriticismOfWiki.

Other Wikis

Meatball is not typical. On most wiki, people just plain don’t like to rework. Reworking is incredibly laborious, and rewards are minimal. Where reworking happens, it’s usually the result of 1 or 2 individuals. It’s far easier for people to remember where they’re at in their heads, than to clarify it all on paper (CommunityLore.)

Reworking

Reworking is a new art and only a few people really seem to master it, if at all. So we rarely see it happen, and if it happens, we are often not that happy with the results. Is this a failure of wiki? Refactoring will not happen in other systems, it will not happen in a BBS or Blog at all. So I think if there is a failure, it is our failure, it’s the failure of the people using wiki. Or maybe the problem is impatience, we have just to try harder and longer to arrive at good results.

Wikis also have quite different cultures, supporting or hindering reworking. Signing is often seen as a major obstacle to reworking and there are wiki communities that discourage signing while others invite signed contributions. So there is no common “wiki” practice in that respect.

CommunityWiki is probably at one extreme of the spectrum, because of its image-signed contributions. They are beautiful but seem to discourage reworking even more than normal signatures do.

Quote

Then again, maybe the first few that really start reworking let other people sit 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 deter other readers from turning into contributors. – AlexSchroeder on CriticismOfWiki

Diagram Summary

LackOfReworkingClassicalFailureTheoryImage

See Also

CategoryReworking

Discussion

Old discussion moved to → LackOfReworkDiscussionArchive 😊

PurposeOfReworking

By defining a shared purpose for reworking content over time, processes for [[Stigmergic?]] reworking are easier to define. For instance, on CommunityWiki, a purpose of TheoryBuilding informs ideas like transcludable AnchoredObjects. In [[Wikipedia?]], the purpose of building an encyclopedia informs the various affordances (“needs reference”,etc) that make it easier for people to see how to collaborate stigmergically.

LackOfReworkingInteractionDesignIdeas

There have been many plausible solutions discussed here, and in LackOfReworkingDiscussionArchive?

I agree that there is a huge SocialFactor?, but this is focusing on an InteractionDesign? and usability perspective. Some of these directions of thinking emerged from discussions between SamRose and TheSheep about DandelionWikiEngine?, and other ideas. Also, from recent reading of BranchingWiki

IntuitiveReworking

The basic premise that reworking is not Intuitive in existing WikiEngine design. The core part of the theory is that useful reworking could happen in stages, based on the way that people first read, then edit pages.

The current expected reworking systems do not take advantage of the ability of machines and software to route content, and to give access to content in a way that is arguably more intuitive for Wiki users.

Reworking as an activity and process, and pattern, could happen in stages, and could use “features” of machines and software code to work with the way that people naturally engage text on websites and wikis.

ContentAsObjects

The idea here is that bits of text become “objects” that can be referenced elswhere, or that can be easily moved, or easily have data attached to them.

Here on CommunityWiki we’ve discussed and experimented with ideas like AnchorObject?, MicroContribution and TransClusion of content from one place to another in the wiki.

An emerging idea explored by JohnAbbe and others is found in the WagnWikiEngine? (http://wagn.org), which treats “pages” as “cards”, allows for very quick http://wagn.org/wagn/inclusion of cards into other cards, by “plussing” (”+”) the card names together.

TransClusion (or “inclusion”) of wiki content within other wiki content is definitely a building block of InuitiveReworking?, but is not enough in and of itself.

However, ContentAsObjects also enables another editing and ContentReworkingPattern?:

ContentAnnotation

Existing intuitive examples include:

The idea here is that first people make their own notes, or InlineComment?, about an existing piece of text. Much like the BranchingWiki idea, these can exist as “branch” objects.

IntuitiveReworkingSpec A user could have a choice to either:

  1. Make a comment annotation about the text content
  2. Make a “branch” edit of the text content
  3. Merge existing branch edits of the text content

A user could do this while reading the content. Comments and Branch edits can be “folded” next to the content, with an icon or other signifier. Any branch edit can also exist as a stand-alone “object” that can be referred to elsewhere by name.

Revision control could be employed, along with scripts that allow the user-interface to call revision control commands, to do Branch edit content merging.

Content objects could also of course combined via TransClusion (or “inclusion”) by making a simple way to “and” object names.

Define external redirect: CommentPress DjangoProject LackOfReworkingDiscussionArchive Wikipedia InteractionDesign InuitiveReworking SocialFactor DrupalAnnotate InlineComment AnchorObject ContentReworkingPattern Stigmergic DandelionWikiEngine WagnWikiEngine

EditNearLinks: ReworkingProblems WhatIsReworking WikiEngine

Languages: