Tags:
create new tag
, view all tags

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

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2004-09-07 - VinodKulkarni
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.