Floated for discussion before inclusion in Refactoring Wiki Pages or Good Wiki Citizen
I now openly question the following from Good Wiki Citizen:
Don't refactor live threads. When people are still going at it hot and heavy, let 'em be. When they all get too disgusted with themselves to contribute any more, still let 'em be. Give it a few weeks for the dust to settle. Then try to fix it. (Hint:
if you got there from Recent Changes, the thread is probably live.) Brain Storm First Clean Later
I've begun to disobey this, first in small ways, more recently in much bigger ways. It's time I came clean.
I don't even apologize.
(Caveat: I've normally at least been part of the thread)
Don't refactor live threads. Is this perhaps a practice to reject now that we've seen its effects, a reason Why Wiki Works Not? If people are continuously refactoring sprawling Thread Mess into coherent Document Mode, no great Thread Mess ever accumulates. More importantly, when virtually every page on Wiki is a Thread Mess, people come to think of Wiki as a purely Thread Mode discussion forum. "Sure, what the hell, I'll toss a rude little barb onto this page. Everyone else is doing it." Letting Thread Mode run without continuous refactoring teaches people a bad way to Wiki. Continuous refactoring never lets people forget that beautiful Document Mode is the goal. -- Ben Kovitz
Why not build a parallel document that attempts to improve the organization? Why dinker with the original if its still changing? We can then rename or remove the original after the dust settles.
The Ayes: (people are known to broadly agree)
If you aren't flamed to death as a result of it, it is probably OK. -- Stephan Houben
I vote for refactoring right then. You're making changes anyway. Now is always the best time to take action." -- Jeff Grigg
I also agree. I've often been in project meetings which made me wish I could refactor a recent comment onto a new page. -- David Saff
Change anything, at any time, anywhere, whenever you feel like it. -- Keith Braithwaite
Delete/refactor all comments that bring no new insights. The more concisely an argument is made, the more strength it carries. -- Laurent Bossavit
The Nays: (one or more people are known to disagree)
If you're impatient, you won't have enough perspective to refactor and delete.
If you're involved in an active thread, you might be biased when you remove text.
You can squash any potentially interesting tangents by being too focused.
Many times some tangential fluff is created to answer some incidental question that doesn't deserve its own page. People shouldn't delete it because the intended recipient and lurkers may not have had a chance to read it yet. See Douglas Hofstadter for a discussion of www.pulitzer.org and Recent Changes Signature to see what happens when you prematurely delete something (someone asks). is the comment on Recent Changes Signature still there?
Actually, lately it seems people are moving fluff onto their own pages anyway. This is really aggravating. Each Wiki Page is just like a class in, say, Smalltalk or Java. Apply Meaningful Names and avoid Ravioli Wiki. See Ravioli Wiki for various views on Ravioli Wiki - avoidable or unavoidable, tasty or inedible
Because you're going too fast, you have to use Refactoring Notes because you aren't feeling confident enough to make the change. There's a rule in writing/editing/programming:
If you aren't sure, you're wrong. I'm being overly harsh here, but take it easy. You can't make good decisions if you're hyped up on adrenaline. The motivation for this page is the (to me obvious) fact that nothing like enough Wiki Refactoring has gone on. Criticising adrenaline here is like saying the water's dirty when you reach the only oasis for 1000 miles in the Sahara. It may be that we only have the required energy to refactor shortly after being involved in a page. All of these criticisms strike me as the work of someone who hasn't refactored much of any real complexity but has been upset that a few words of his own have recently been lost.
Previously in the list of "Nays":
It turns Recent Changes Junkies into tail chasers. I write something, the rabid refactorer goes and refactors it right away before I'm done thinking through my contribution. Then, someone refactors the refactoring. And so on.
If they're refactoring things "away" then they're discarding information. If information is discarded then there is a problem with the refactoring, not with its timing.
Makes sense to me. After all, the XP people don't wait until a certain part of the program "has settled down" before they refactor, on the contrary, they refactor before adding new stuff.
XP doesn't work when you want to do exploratory work. You know, to go off on tangents and see where takes you. If you immediately cut off all potentially interesting points, you'll destroy the whole point of randomly smashing words together to spawn a new discussion. Actually, XP only works when you have requirements. See Improve Signal And Readability.
After fourteen months I'm tempted to delete the yet
Churning old pages is a great feature/misbug. It works like your mind when something triggers an old memory that launches you into a new direction. However, with New Notification, that's kind of broken now. :(
The moral guidelines have been deleted in favour of the more strenuous and accurate ethical framework set out in Changing Signed Contributions.
There is a problem with Deletion In Wiki. It seems to me that refactoring is meant to capture the essential essence, distilling it in places, reorganizing it in other place, and removing non-contributory elements to another place or removing them. Deletion should be reserved for segments or pages which in the view of the community (not an individual) are not wanted, or are not helpful. It is well to be cautious in refactoring to be sure to reflect and retain as much of the original essence of the page as possible. (See Trust And Responsibility)
That's what's meant by deletion in the title of this page. For information on Deletion, See Deletion In Wiki.
See original on c2.com