Refactor Faster Delete More

Floated for discussion before inclusion in RefactoringWikiPages or GoodWikiCitizen

I now openly question the following from GoodWikiCitizen:

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 RecentChanges, the thread is probably live.) BrainStormFirstCleanLater

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 WhyWikiWorksNot? If people are continuously refactoring sprawling ThreadMess into coherent DocumentMode, no great ThreadMess ever accumulates. More importantly, when virtually every page on Wiki is a ThreadMess, people come to think of Wiki as a purely ThreadMode discussion forum. "Sure, what the hell, I'll toss a rude little barb onto this page. Everyone else is doing it." Letting ThreadMode run without continuous refactoring teaches people a bad way to Wiki. Continuous refactoring never lets people forget that beautiful DocumentMode is the goal. -- BenKovitz

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. -- StephanHouben
I vote for refactoring right then. You're making changes anyway. Now is always the best time to take action." -- JeffGrigg
I also agree. I've often been in project meetings which made me wish I could refactor a recent comment onto a new page. -- DavidSaff
Change anything, at any time, anywhere, whenever you feel like it. -- KeithBraithwaite
Delete/refactor all comments that bring no new insights. The more concisely an argument is made, the more strength it carries. -- LaurentBossavit

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 DouglasHofstadter for a discussion of http://www.pulitzer.org and RecentChangesSignature to see what happens when you prematurely delete something (someone asks). is the comment on RecentChangesSignature still there?
- Actually, lately it seems people are moving fluff onto their own pages anyway. This is really aggravating. Each WikiPage is just like a class in, say, Smalltalk or Java. Apply MeaningfulNames and avoid RavioliWiki. See RavioliWiki for various views on RavioliWiki - avoidable or unavoidable, tasty or inedible
Because you're going too fast, you have to use RefactoringNotes 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 WikiRefactoring 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 RecentChangesJunkies 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 ImproveSignalAndReadability.

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 NewNotification, 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 ChangingSignedContributions.

There is a problem with DeletionInWiki. 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 TrustAndResponsibility)

That's what's meant by deletion in the title of this page. For information on Deletion, See DeletionInWiki.

CategoryWikiMaintenance