Monday - Interview with a Wiki Ninja
Tuesday - TNWiki Article Spotlight
Wednesday - Wiki Life
Thursday - Community Wins
Friday - International Update
Saturday - Top Contributors of the Week
Sunday - Surprise
Wiki pages can be divided in categories. I’ve blogged about several of those categories in the post, such as:
Today, I’d like to talk about another type of Wiki page, the Wiki scorecard…
A very wise person once wrote:
“A scorecard provides fast and better insight…”
Okay, maybe it wasn’t a “very wise” person. Maybe I wrote it myself. Maybe I wrote it for a business intelligence chapter in an MS Press book. Nevertheless, it nicely sums up what is cool about scorecards. As it turns out, scorecards can be dangerous to, considering the “What a stupid I am” anecdote at http://www.anecdotage.com/index.php?aid=16015.
On with the story… In the IT world, a scorecard is usually written by some vendor who compares his product to others like so:
Conclusion: My Product is the best!
I always wonder if such a list is fair and complete, and I’m always pretty sure it isn’t. If you could look into my mind, the previous scorecard could very well read like this:
If you pronounce it right, “SQL” almost rhymes with “Smeagol”, the hobbit who became corrupted by the One Ring
Oracle rhymes with “Bworrkul” which isn’t really a word, but is useful in sport events nonetheless
Hard to say which product won this battle, but my vote goes for SQL Server. Maybe we can decide the winner using the Comments section of this blog post?
Anyway, I feel that Wikis are great for keeping scorecards. The community gets a chance to alter the list of features/benefits or whatever, making it very plausible that this list will be exhaustive in the sense that all major topics will be listed. It’s also a better way to make the score section more balanced: everyone gets a chance to score. It just seems fairer and less biased that way. Thus far, I’ve only written one scorecard Wiki, here it is: http://social.technet.microsoft.com/wiki/contents/articles/9638.sharepoint-2010-best-practice-keep-relational-data-in-a-database-or-migrate-it-into-a-custom-list.aspx