Wiki surely suffers from the absence of MercilessRefactoring. I am interested in schemes whereby refactoring can be introduced into a mature environment without creating chaos. A recent submission to PLoP suggested that document reorganizations should always be delayed until demanded by readers. We've seemed to muddle along by layering new organizations, like categories and roadmaps, on statically named pages. I wonder what others think of wiki's approach to BalancingReadersWritersAndEditors. -- WardCunningham
Discussion:
There are far more readers than there are writers, and more writers than editors. Statistics on this have been given in the past as being 10 to 1 in the first case, while the number of editors can probably be counted on one hand.
Readers
It is because pages are to be read by someone that they are created in the first place. Value is added to the pages by the hyperlinking of related and supporting pages. If the page is well constructed, factual, and informative, people will read and appreciate the material provided and the contributions made by the community in its construction. One difficulty encountered by readers on many pages is the lack of a central and focused theme to the page. Often it presents a fractured and unharmonious presentation. Such pages often are refactored and/or removed by Editors and Refactorers.
The manner and method of navigation through pages has utilized a number of mechanisms in addition to the hyperlinked references found on most pages and the RecentChanges. One such method is that of classifying and categorizing the page as belonging to a theme, thought, or grouping. This is accomplished by assigning a category to the page. While this is helpful in guiding some readers, it is not always used wisely and the scheme can often be flawed. Roadmaps are a little more structured and require planning and organization as well as an advocate willing to create such page. Readers may also utilized the search (find page) process to locate items of interest, as well as the reverse link and like pages processes. Also useful is the VisualTour graphical hyperlink process available on each page.
Writers
Writers are adding pages every day, with varying results. Some pages authored are thoughtful and well constructed and are harmonious with the guidelines established. Some are frivolous, not well thought out, and poorly presented. This can often be explained by the lack of writing experience or shallow understanding of the topic. These are not lost causes, because through participation of others, collaboration, discovery and investigation of the theme, order, accuracy and depth can be introduced. Pages authored are most often discovered via the RecentChanges Page. People new to the Wiki sometimes author pages with little or no content as a result of their testing of the Wiki editing facility. These are quickly identified and the writer is encouraged to either add content, or take the testing to the sand box. There are few incentives offered to those who might be writers, so the number of new pages created each day which survive number only about 10 to 20. >
ShallowPages are created for a variety of reasons. While lack of writing experience, shallow understanding etc do explain some of the situation above, I feel the CollaborationLeadsToDiscouragement phenomena is probably a bigger barrier. Just in the last week (Oct05) I have observed another longtime Wiki enthusiast muttered about him being "stalked" for his contributions that were SignedWithaPurpose.
Other reasons for starting a ShallowPage:
Editors
Perhaps not enough good editing, but far too many editors -- once the majority of the new content is related to how/when/why to edit/delete/refactor, the real information value gets lost in the drivel. -- JimRussell
I think the prevailing outlook is a little pessimistic.
Wiki still has a lot of value hidden away in its pages, some oldies and goodies, some that have matured over time. The trick is to move the good stuff to the top of the heap by refactoring. If we try to make refactoring more rewarding, we might be able to stir up some more support. Pages like ThankYou might be a start. It's certainly harder to refactor than just add more stuff, but it's not terribly harder. I think people think it's harder than it is. They see a big page and lose motivation because they don't know where to start. Maybe gathering and generating pages on how to refactor would help. We could also try to set up some form of collaborating. Refactoring Wiki tends to be rather lonely. Maybe a sign up page for pairs to get together and refactor a specific set of pages. -- RobHarwood
[Don't forget that SharkBot reverts away the FixingBrokenWindows? work some of us non-GV users do. If we can't accomplish anything, why bother?]
FrancisHwang, IMO, has been the most successful refactorer that I've seen so far. He's also come up with some pretty good ideas such as RefactorLowHangingFruit. -- anon
Well, far be it from me to disagree with praise, but I should point out that I did not actually write RefactorLowHangingFruit. I've been writing more arcane, specific tips like RefactorTowardsTheCenterOfThePage, SplitByTopicNotByOpinion, and DontNamePagesThoughtsIssuesIdeasOrOpinions. All of which seem to work for me, but perhaps they aren't so universally useful. -- FrancisHwang
Refactoring is tricky where there are so many links, all "hard coded" by smashing words together, which could be invalidated by the change. What is needed IMO is a more dynamic linking system, where perfectly plain text becomes highlighted as a consequence of being simply introduced into a wiki-style environment. E.g. there is a page somewhere in the system called "perfectly plain text", so all the occurrences of the phrase "perfectly plain text" on this page (or maybe just the first occurrence) automatically become links to that page. Then, when a page is renamed, a lot of links might get broken, but they don't *look* broken. More positively, a lot of new links might get made, without the need for a lot of human intervention.
Pros: Text can be introduced into the wiki which was perhaps initially intended for some other purpose. E.g. a text such as the Iliad can be converted into a hypertext simply by packaging it together with a dictionary of mythology. Underlying structure in the text automatically emerges, instead of having to be teased out manually.
Cons: Smashed together words in a text can be a useful placemarker, for a page that hasn't been written yet but will be RealSoonNow. They can also indicate that there was once a useful link, and it has gone. Automatic linking to phrases can result in a lot of AccidentalLinking (in fact, that is the point of it, but some of the accidental linking will be inappropriate).
To get the best of both worlds, allow links of both kinds.
I think it would be more trouble than it's worth. If I type 'refactoring databases', does that link to two pages or one? Or three?
In my approach, 'refactoring databases' refers to one page if there is a page called 'refactoring databases'. If there is no such page, but there is one called 'refactoring' and one called 'databases', then there are two links. The system always checks for the longest possible links first.
Actually on the 'refactoring databases' page, however, a link to the 'refactoring databases' page would be redundant. In that case, the phrase is not highlighted and the individual words are checked to see if they should be highlighted. The only problem I have is frequent accidental linking, especially when I have pages with titles that are a single commonly used word. Usually the accidental links are useful, but there are problems when there is an acronym that is also a commonly used word, since I ignore capitalization.
I'm new here, so to me editing looks easy but I'd feel uncomfortable about refactoring the work of others who've been around far longer than I have. To do it properly, I would have to have a good feel for how the discussion has developed. I wouldn't want to undo somebody else's refactoring, which might happen if they have a different opinion from me about where things belong, and about what is important. I don't know how long it will take for me to get into refactoring, but I suspect that most people will feel uncomfortable about it for a long time. Especially if they are only occasional casual visitors, not regulars. -- MartinGradwell
I didn't read through this page because it is too long. But obvious refactoring. There should be a RenameLink? option that will automatically go through the database and rename all the references to this renamed linked. --RobertDiFalco
AutomaticRenaming? is tricky. (I think this is discussed elsewhere, but I can't remember where right now.) The problem is that many links are used in-sentence, and changing them automatically will render them nonsensical. -- FrancisHwang
I guess I don't see mid-sentence links as that big of an issue. There are a couple of things you can do. Offer a list of pages with mid-sentence references and allow editing of each, or keep the previous link, escaped, with the new link. Something like:
I hate the ArchitectingWord.
Becomes
I hate the ArchitectingWord (see: ChiefArchitect).
While I could see this working, it still seems like more trouble than it's worth. It isn't really that hard to move a page and change the old page's content to say "See N'ewPageName". While a more fancy renaming facility might be useful, I still don't see it solving the main problem; that people aren't refactoring individual pages enough. ~ francis
Would it break Wiki to have some kind of a trial method where votes on if it improves understanding? Add something like Slashdots meta-moderate to a system of editor metrics and the rate that a newly refactored node is moved from the trial balloon area to the primary wiki.
It probably wouldn't break c2, but it certainly might encumber it. What's the point of anointing a special process? If you want to learn to refactor, start refactoring. Simple as that.
I like the idea of having a formal page and an informal page per topic. This is similar to creating a "discussion" page per topic, but I think it should be built into the wiki engine. The formal "opening" page has concise summaries of ideas and pros/cons, while the discussion page is allowed to be a bit messy. It would almost be like the "talk" tab in wikipedia, but be about topic-related info instead of a meta discussion.
Related: