In my opinion one of the best ways of getting “knowledge” out is through weblogs. This is exactly what a lot of people are doing. In out company everyone has access to its own internal weblog, and this is the way information is best shared within our company.

When I was setting up these weblogs I was also planning to create automatic categories you could assign your weblog post to, based on the SharePoint topics struxture, and based on the list of projects we are working on. It never came that far.

I still think it is a good idea, and an “easy” way to collect one part of the collective knowledge on SharePoint. Can’t we come up with a set of common post categories we assign our weblog entries to? Each blog engine support categories and separate RSS feeds on them. We could collect those RSS feeds into one big RSS feed, and based on these RSS feeds create a site that displays all collective knowledge categorized to a fixed set of topics…

But then the biggest issue: comming up with a set of common post categories... I’m afraid that part will brings us into taxonomy hell… to what level of detail do you define categories, how many categories are needed, etc. etc.

Bil Simser describes in post http://weblogs.asp.net/bsimser/archive/2005/06/22/414258.aspx a “bug” he encountered with versioned document libraries. When a document is saved in a versioned document library, the timestamp of the then latest version of the document gets changed to one minute before the time stamp of the new saved document.

This problem is related to one of the biggest problems I have with document libraries. A document in a versioned document library becomes a "version" when a newer version of the document is saved.

An example:

I create a document called “VersionedDoc.doc” in the document library “http://myserver/personal/serge/VersionedDocumentLibrary”.

It is good to hear that weblogs post can make waves within Microsoft walls…

It is good that it is possible to do the modifications through code, as Ryan stated. We have an escape! A costly one if you have MANY site instances, because the pages you modify will become unghosted (a copy is created) in the database… you remember, that issue you try to prevent by not modifying pages through FrontPage;-) But hey… storage is cheap these days!

Another issue I had are the MySite pages… you don’t want to have to change 30.000 My Site pages if you need a small modification to the private or public view. Good thing is that the MySite public and private pages are handled differently from normal sites… if you modify the MySite homepage as an administrator in “Shared View” it changes for all users! These pages are in a special location: