KB-tool

Problem

Technical support, sales teams, and other front line responds need to have access to a large amount of shared knowledge, which is best stored in a shared repository. However, most mediums for storing this information are difficult to use, hard to search, and in most cases teams will opt for full memorization of this information rather than be able to rely on the resource because the "access costs" are too high.

The result is that the learning curve is too high, teams waste energy building and maintaining resources that they can't use, and teams incorporate new information slowly because there's no way to update "shared brain state." consistently.

Design Objectives/Principals/Patterns

• Knowledge is stored atomically. One response, piece of information, or fact, per file.

• A small number of very high level directories separate the files into more manageable situations.

  An NOC support department might have directories like: "outage or crisis, abuse, billing, hardware, peering, and general." A sales/marketing team might have directories like: "competition, case-studies, presentations, proposals, white-papers, and general."

• An interface wrapper script allows users to input simple structured queries, and returns the content of 1-5 pieces of information. If the query misses, a list of possibly relevant (i.e. near matches or items in the same major category) will return.

• A Makefile, to:

  • build an index after the content is updated.

  • automatically synchronize updates using git or similar

  • export the content to web-publishes using ikiwiki or preferably using Sphinx (the documentation system used by the Python Project.)

Tasks

TODO develop design

TODO being development