If the wiki is configured as a site or subsite, you can assign a primary and secondary owner. Sharepoint can be configured to prompt the owner(s) to confirm the site’s viability every , but that period is set for ALL the sites, it’s not on a site or subsite basis.

I’ve been motivated to install and check out CKS:EWE (Community Sharepoint Kit: Enhanced Wiki Edition) for months now but some thing or another keeps coming up that prevents it…I have high hopes for it however.

http://www.codeplex.com/CKS/Release/ProjectReleases.aspx?ReleaseId=8087

If the wiki is configured as a site or subsite, you can assign a primary and secondary owner. Sharepoint can be configured to prompt the owner(s) to confirm the site’s viability every , but that period is set for ALL the sites, it’s not on a site or subsite basis.

I’ve been motivated to install and check out CKS:EWE (Community Sharepoint Kit: Enhanced Wiki Edition) for months now but some thing or another keeps coming up that prevents it…I have high hopes for it however.

http://www.codeplex.com/CKS/Release/ProjectReleases.aspx?ReleaseId=8087

If implemented correctly, it can spur massive momentum in the development organization, as well as the overall organization.

Further, it can improve morale and serve as a catalyst to charging professionals careers – much like blogs are doing on the Internet. In alot of ways, the same phenomenon.

The openness of a WIKI is like the openness and success of open source software. Through collaboration, open source went from being ridiculed or pshawed to serious business cases and profitable companies over the years. Through collaboration, no one that is collaborating will want it to fail.

In fact – the best selling (and best working!) WIKI on the market – Atlassian Confluence WIKI is also a successful business COMPLETELY built on the premise of collaboration (their doc and their plugins). Their own product and websites are the best case example of how to WIKI correctly. Lead the contributors through a configured structure (that can evolve), entice collaboration, and moderate as needed – but not heavy handed. (http://www.atlassian.com)

With WIKI’s internally, when embraced – people start taking more care in their work, care in presentation, care to express things easier, and simpler, and clearer. Designs are flushed sooner, up front – and design specs that are often skipped, start becoming reality – and in a collaborative way. Checks and balances happen on the WIKI, not on the 11th hour when trying to do a final build.

BUT – it’s all in the implementation.

I have seen way more bad WIKI implementations than good ones – and the only good ones happen because of a moderator – not heavy handed, but someone also serves as a champion for the cause.

Someone who cares. Someone who rallies. Someone who promotes it internally.

Often WIKI and issue tracking systems or other support systems are deployed by IT – and left to the masses – with no real over see-er on the process, or lack of process (as the case happens with WIKIs – and then all of a sudden, there is simply a mess to deal with).

Someone that has a vested interest in the cause is often the best candidate for this, like a technical writer or a PM. If more people eagerly contribute, all the better and smoother their job becomes as well – and the writer is not left in the back room to flail with little to no input because everyone is too busy to care about their key objective too.

Regardless though – whoever is moderator – the key in effective WIKIing is NOT obsessive control at the Admin level. Obsessive control stiffles the flow, for sure!

Seen this too. And without the flow – well what’s the difference. Might as well just go back to sharing emails.

Open and engaged flow to create a team environment is core.

Just my thoughts …

I see NO cons in WIKIs, except languishing ones without a nurturer.

If implemented correctly, it can spur massive momentum in the development organization, as well as the overall organization.

Further, it can improve morale and serve as a catalyst to charging professionals careers – much like blogs are doing on the Internet. In alot of ways, the same phenomenon.

The openness of a WIKI is like the openness and success of open source software. Through collaboration, open source went from being ridiculed or pshawed to serious business cases and profitable companies over the years. Through collaboration, no one that is collaborating will want it to fail.

In fact – the best selling (and best working!) WIKI on the market – Atlassian Confluence WIKI is also a successful business COMPLETELY built on the premise of collaboration (their doc and their plugins). Their own product and websites are the best case example of how to WIKI correctly. Lead the contributors through a configured structure (that can evolve), entice collaboration, and moderate as needed – but not heavy handed. (http://www.atlassian.com)

With WIKI’s internally, when embraced – people start taking more care in their work, care in presentation, care to express things easier, and simpler, and clearer. Designs are flushed sooner, up front – and design specs that are often skipped, start becoming reality – and in a collaborative way. Checks and balances happen on the WIKI, not on the 11th hour when trying to do a final build.

BUT – it’s all in the implementation.

I have seen way more bad WIKI implementations than good ones – and the only good ones happen because of a moderator – not heavy handed, but someone also serves as a champion for the cause.

Someone who cares. Someone who rallies. Someone who promotes it internally.

Often WIKI and issue tracking systems or other support systems are deployed by IT – and left to the masses – with no real over see-er on the process, or lack of process (as the case happens with WIKIs – and then all of a sudden, there is simply a mess to deal with).

Someone that has a vested interest in the cause is often the best candidate for this, like a technical writer or a PM. If more people eagerly contribute, all the better and smoother their job becomes as well – and the writer is not left in the back room to flail with little to no input because everyone is too busy to care about their key objective too.

Regardless though – whoever is moderator – the key in effective WIKIing is NOT obsessive control at the Admin level. Obsessive control stiffles the flow, for sure!

Seen this too. And without the flow – well what’s the difference. Might as well just go back to sharing emails.

Open and engaged flow to create a team environment is core.

Just my thoughts …

I see NO cons in WIKIs, except languishing ones without a nurturer.