Using TWiki for Knowledge Management
To create a standard deployment guideline specifically for Knowledge Management in a typical group or organization, and to track various issues that need to be tackled.
While TWiki can be used today as informal and ad-hoc mechanism to manage knowledge, what do we require to make it more formal, so it can be seriously considered for managing knowledge elements related to organizational processes?
Various issues:
- Long-term persistence of references of content within twiki: Need a good solution (and integration with apache?)
- Can't refer to topic names as is, since contents can be changed any time. Instead, create 'published' versions mapping to specific topic versions.
- Published URLs need to be short.
- Normally, the actual content would be attachment (PDF/Doc file) - can be emailed etc. (and is seen in more formal light, as opposed to a HTML page).
- Policies for content of a published page
- Can't have URLs referencing other topics; but can reference other published documents. Wiki-word interpretation is disabled (and any reference is explicit.)
- Standard document templates with author, date, change information embedded
- Workflow for submission+editing+publishing cycle.
- Need to support document Repositories along with wiki topics for the content sources.
- Access control system
- Notification for events
- Applying classification / Taxonomy, layout etc.
- Classification / Taxonomy mechanisms and Layout
- Allow multiple hierarchies etc.
- Managing relevance, aging
And perhaps many others. What are the current approaches that the community is using? It will be nice if we can identify gaps, and perhaps still provide a deployment guideline with existing capabilities.
Related Topics: TWikiInALargeCorporateSetting,
ContentManagementSystem
Note: Focus on a solution, content layout, taxonomy/classification mechanisms etc. This might involve integration with other content management systems as well.
--
VinodKulkarni - 23 Jun 2004
We have the problem of conflicting information in diffeent topics due to different information states at different creation/editing times of topics. (usually nobody cleans old twiki topics) A solution would be to label the entire twiki topic state for a given publishing time.
--
PatrickKlinkoff - 06 Sep 2004
In organization context, I suggest these possibilities:
- Have a similar look and feel in all "formal", autoratative topics.
- Appropriate navigation that will direct you to the most current information
- Within the template, put a time period of validity of the information, and who created the information (role, and actual name)
And a regular process that will identify expired topics and re-validate them.
At project level, things tend to be ad-hoc; but somewhat strict discipline of related topics and gateway topics could help in figuring out the right information.
In fact, twiki.org is one good example of it. One can typically track almost all the discussion that went into deciding certain implementation of a feature - almost in one shot. If the project team only uses mailing list, then at best, you have do some search (and a lot of overhead). Twiki is also used more formally to track things like features, testing, tasks and even bugs. When used this way, you would almost always go in for a template based topic creation and some workflow put-in as part of standard processes. Other ad-hoc topics can then be created from these topics, and therefore be traced back to the original context through parent-child relationship.
--
VinodKulkarni - 07 Sep 2004