ColdBlanket

MeatballWiki | RecentChanges | Random Page | Indices | Categories

A ForestFire in a wiki context refers to lots of new (and undesired) pages being created in a rush. The ColdBlanket is a possible reaction to a ForestFire:

Cool down! No more new pages without finishing old pages.
No more WordMagic! Add flesh to your pages. Put them into context by linking them into the system.
Delete ShallowPages! A wiki is not a dictionary.
Delete links to non-existent pages! AvoidClutterLinks.
Refactor faster! Remove loose ends, half thoughts, and anything off-topic

The ColdBlanket is one of the roles of CategoryRole; its purpose in life is to DefendAgainstPassion. The irony may be that the ColdBlanket is too passionate about impassion. The danger is that the ColdBlanket goes beyond reinforcing and explaining BehavioralNorms to squash actual ideas.

A ColdBlanket is often a failure to provide ActiveEngagement?. It's a cheap shortcut where no shortcut is to be had. Rather, time must be invested in bringing the contributor into alignment with the CommunityExpectations through careful and constructive teaching. This presumes, though, that the contributor is willing to be taught. Most of the time this is the case provided the community maintains the PrincipleOfConstantRespect.

This kind of approach is chilling. It may offend newcomers, and it will stop brainstorming cold in its tracks. This is the wrong thing to do if EnablingCreativity is one of your goals.

While I guess the approach itself is chilling to some degree, in my opinion what scares away newcomers is not the cold-blanketness but rather the presentation. I think MarkDilley has the right idea about how to explain things to newcomers. I think the number one thing that scares away newcomers from here might be the you-did-something-wrong overtones of requests to change. The number two thing might be the crypticness (our rules, regulations, and requests must be pretty hard to follow by someone who doesn't know how to use wiki). -- BayleShanks

Point taken. I'll try to keep an eye on it. ;) -- AlexSchroeder

I think that ChristopherAlexander has to say a lot about these things. But no-one here has read his last book, so no discussion has yet developed. He talks about 15 characteristics of living systems, one is "roughness" which means that systems shouldn't be too perfect, too regulated. His samples of beautiful things almost always show the signs of age and use. On the other hand there are many characteristics that directly work towards symmetry and items that have to do with order. So I think the secret may be to have rules and order, but to be not too strict when they are violated with a good reason. -- HelmutLeitner

There's a tension between cold blankets and more exhuberant creative folks, but it can be (should be) a creative tension and HealthyConflict. Ideally a given page, or a given wiki, will cycle through periods of expansion and contraction, to match the seasons. -- MartinHarper (ie, ReworkLater)

A better approach is to constructively teach people how to write more effectively, not to chill out the discussion with tiresome snooty boredom. While I recognize this is the proper approach, the trouble is that it is tedious to continuously do this. Eighty percent of the problem is that the CommunityDoesNotAgree that good writing is important, or maybe what constitutes good writing. This means that the task of teaching better writing falls on only the same small set of people instead of becoming part of the CommunityExpectations and CommunityLore, and thus it does not osmotically infuse to all new writers. Moreover, editors often have to fight when editing, which is one of the GreatChallengesToWikis.

Unfortunately, new skilled writers are rarer than new unpolished writers, and the new skilled writers still need time to learn how to teach writing. The inability to grow teachers faster than contributors puts a negative pressure on community growth. We feel that we need to put a ColdBlanket on growth for awhile. Further confounding the problem, good editors get tired of chasing after messy writers instead of training them in how to write effectively. How often do we refactor the PageDatabase? While statements like this usually generate one or two (zealous) refactorings as a reaction, it doesn't actually solve the problem of creating a CommunityExpectation for continuous refactoring.

The only way to help a person is to constructively engage them, and that means criticizing them (constructively) when appropriate. They usually won't bite back; if they do, they probably aren't well suited to BarnRaising anyway. Most will appreciate you are helping them improve their writing and communicate their ideas. After all, we are a collective, which means we actively help each other, not merely avoid hurting each other. That's our advantage. Our skill and our cooperativeness. -- SunirShah

: I think the problem for continuous refactoring is just that the RecentChanges view into the database is the best one we have. Refactoring the page database requires reading many pages, understanding them all, then throwing them around - something perhaps best aided by wandering around a visual representation and looking for clusters, before working out a replacement cluster on paper.(It's incidentally rather hard to revert if the work done is not appreciated, but perhaps that's just my apprehension.) RecentChanges provides no help nor impetus to do this.

: Do you feel anywhere in particular needs a good spring clean, Sunir, or is this a general thing? Myself, I'm still wondering how best to redo the MeatballWiki cluster - will post when ideas coherent - and will move on elsewhere when I'm done there. -- ChrisPurcell

Perhaps this should be moved to RoleOfRecentChanges.

Following my general biases, I feel the real problem preventing refactoring is personal time and InformationOverload. Namely, RecentChanges is the only way to "keep up" with conversations on a non-threaded wiki. Worse, RecentChanges demands your time now. If one ignores RecentChanges for more than a few weeks, one loses the ability to see only the new responses on pages, and then the problem of seeing if there were any replies to conversations that you were interested in becomes unmanageable.

Hence, when I visit MeatBall, I get the feeling that my first priority must be to check RecentChanges. I don't have much spare time, so often I don't even get through that. I'd love to refactor more (as opposed to commenting more), but not at the expense of not tracking conversations.

So, I feel that the solution is to add some other tool that either allows one to track conversations without RecentChanges (see ThreadingForWiki or CatchUp), and/or to reduce the amount of time it takes to go through RecentChanges (see FilterMore).

-- BayleShanks

CategoryConflict CategoryRole CategoryJargon

ColdBlanket

Discussion