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.
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.
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 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.
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.
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
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.
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.
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.
Existing intuitive examples include:
IntuitiveReworkingSpec A user could have a choice to either:
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: DrupalAnnotate InteractionDesign WagnWikiEngine InlineComment InuitiveReworking DjangoProject Stigmergic CommentPress Wikipedia DandelionWikiEngine LackOfReworkingDiscussionArchive SocialFactor ContentReworkingPattern AnchorObject