Wiki Author Discussion

From: WikiAuthor

To explore the idea on this page, how would you change a page like CodeOwnership, which is valuable not only for the ideas it expresses for and against code ownership, but also valuable for who said what? Should wisdom from people with the experience of JimCoplien and KentBeck be taken more seriously than wisdom from some other people?

Make the page SignedDocumentMode and add each name to the list of contributors. If there are two opposing views consider creating two DocumentMode pages so that each point of view stands by itself instead of as an argument against the other point of view. However, if the page is impossible to refactor, if it has become too big a job, this WikiAuthor would probably leave it alone.

Another frequently practiced alternative is to move the discussion to its own discussion page, and then create a summary, synthesis, or overview on the original page. This practice preserves all of the original context (for those who think it is important), and gives the summarizer a very free hand in constructing the summary.

Much of the conflict on Wiki occurs when people disagree about how (or whether) to replace good text that could still use improvement. Most of that conflict can be avoided by setting the original version aside while working on a proposed improvement. If the original authors agree that the new summary/document is better, they can delete their parts of the discussion with very little controversy. (If the original authors have left Wiki, deleting their old discussion will be controversial.)

In some cases it is useful to separate opposing ideas and give each of them a section or even a separate page. For instance, one could extract the "single developer" part of CodeOwnership to a new IndividualCodeOwnership? page, similar to the existing CollectiveCodeOwnership and CodeStewardship pages. The more generic CodeOwnership page could then give an overview of each of these forms and general topics (like the meaning of "ownership"), with links to individual pages that explore the various strategies.

Getting messier, sorry

For a very lightweight set of tools designed to help refactorers in the improvement of certain kinds of ThreadMode, see MeaningOfDoubleDash. These are proposed on the assumption that it is not always preferable to aim for either DocumentMode or SignedDocumentMode at every stage of a page's evolution. For example, the WikiAuthor or refactorer may consider that there is important signal in certain signatures, such as JimCoplien's and KentBeck's in CodeOwnership. See also TomStambaugh's argument in DeletionInWiki that signatures should almost always be treated as significant.

CodeOwnership it appears to be a pretty straight forward SignedDocumentMode page contributed by JimCoplien. Unfortunately, its cogent text has been overrun by ThreadMode debate. In this case, I might refactor all of Jim's comments and refutations into a nice single SignedDocumentMode piece and then move all the remaining ThreadMode stuff into a CodeOwnershipDiscussion page. The WikiAuthor page takes a different position from those comments on DeletionInWiki since, WikiAuthor does not consider refactoring words into SignedDocumentMode to be the same as deleting words. We view signatures with the same importance as they are viewed in ThereforeBut. In other words, they should be culled into the list of contributors. This is because the WikiAuthor views text as CollectiveCodeOwnership views code.

Do I espy a poacher turned gamekeeper? They make the best ones, so I'm told. I totally trust your judgment on CodeOwnership. Partly I have to. I'm not intending to look at it before you do the deed. Even more importantly, there is enough intense energy required for the critical study of even a medium sized WikiPage, with a view to effective refactoring, to make it pretty uneconomic for us not to trust each other the best we can.

Two points on the DeletionInWiki reference:

I think, but Tom would need to confirm this, that Tom's point about the value of signatures in DeletionInWiki was broader than just naive "deletion". Certainly he addresses the situation of the apparent redundancy between two pages on Strings in Java, saying in effect "keep the two accounts and the two signatures because the fact they arose at the same time is itself important signal". I think that it's a matter of judgment but I think that on occasions Tom would definitely be right.
The debate on refactoring on Wiki has in any case I think been over-simplified and wrongly polarised by our not adequately defining what we mean by "deletion" or "reduction" (it sounds simple but it isn't). ImproveSignalAndReadability still summarises my own ideal best, ahead of any pejorative term. I think Tom was making some good points about how to ImproveSignalAndReadability or at least how not to do the opposite, even if he might take a stronger line against some kinds of "deletion" than I would.

-- RichardDrake

The principles stated at the top of WikiAuthor sound more like WikiFacilitator? than WikiAuthor, since they take a no-identity, no-conflict position. Through opposition, we become stronger. In an open medium designed for collaboration, that seems inevitable. As JerryWeinberg would say, there's nothing wrong with conflict, as long as you keep the 'con' in there. 'Flict' by itself is not so hot. Let's not be so quick to equate document with quality and thread with crap. I'd rather watch a good tennis match than listen to the sports news wrapup. William Shakespeare and others found good quality in thready presentation. How about aiming for good threads and good documents (summaries), where each is appropriate?

As for the quote about better places than Wiki to hold a conversation, it may be true in a technical sense, but misses the depth of quality in the Wiki community. Saying "don't thread here" is a form of saying "don't collaborate here", and in that light is ridiculous. But as I write this, I realize the same slippery dynamic as the software quality one emerging. One guy says "do it right". Another says "just do it, then improve it". The first guy retorts "no, you can do better than that". The second guy retorts back "no, because you'll get paralyzed trying". And back and forth it goes. Somewhere in the center is a truth worth targeting, but no one seems to be able to split that hair once and for all (because it's a people problem). So it is with the present discussion. The best advice I can think of for myself and others is: For the most part, contribute thoughtfully and diligently, and avoid mental lazyness that makes others do your thinking for you. But know when you've done your best, stand back and let others improve it. If there's a thread taking shape instead of a document, DON'T PANIC: IT'S NOT THE END OF THE WORLD. It's not the end of Wiki either.

There's garbage thread, and there's thoughtful thread. I think the presence of the latter is the finest compliment its participants can bestow on Wiki, because it means the forum is so open and alive that they will trust the smallest incubus of an emerging idea to its care. It doesn't get any better than that, Ward.

--WaldenMathews

there are better places than Wiki to hold a conversation

I've never been quite sure that Ward wasn't understating his genius in that quote.

I don't think that Wiki competes with a good chat program like AolInstantMessenger for real time interaction. Email obviously has its uses, not least confidentiality. But I think that Wiki is a wonderful place to have a conversation. This is partly due to being able to reference a concept like DocumentMode. The document type pages are key then in allowing one to have the most wonderful conversations with people. People you didn't know were going to take part when you started, people you didn't know existed when you started.

It's partly this sense of gratitude for the privilege of Wiki conversation that makes me want to clean up ThreadMode for future readers. Not always, maybe not often converting to DocumentMode. But removing RemovableImperfections? that inevitably arise in a "real time asynchronous" conversation to make it easier for later readers to get a feel for the buzz of being part of the conversation at the time. This should be done soon after the main flurry subsides (so RefactorFasterDeleteMore but not too fast), requires good editing skills but needn't include removal of RealNamesPlease. -- RichardDrake