Back to Faq Project

---

The Current Method

How:

• A new FAQ:
  • An FAQ is a text file. It is received by Nathan via email.
  • After a look over, Nathan saves this in the "common" directory on Red.
  • From there, it is placed onto the web (the public C&C website) using rsync.
  • Simulataneously, it is placed into Nathan's staff web publishing area, where FaQFiNDeR can find it. This is also done using rsync.
  • After all these processes have been completed, Nathan emails the relavant persons (generally is-routers) announcing the existance of a new FAQ.
  • At the sight of this email, the Routers Ref (RR) Admin (Bob) enters into the RR admin area and adds an entry in RR describing this FAQ: filename, title, owner. From there, in RR, this FAQ can be associated with specific Topics and Categories.
  
  
• Out of date FAQs:
  • If an FAQ is out of date, it is saved in the "boneyard" directory by Nathan, which exists in the "common" directory on Red.
  
  
• Searching FAQs:
  • To search FAQs, Nathan made a FaQFiNDeR CGI script. It resides in his home directory.
  • RR uses the output of this script to generate FAQ results in its search interface.
  
  
• Using FAQs:
  • Routing is performed on Red. When answering questions, routers can choose to read-in the FAQs directly from the Red Common directory. If sufficient, sometimes the QNA faq request is used. QNA will send the file it finds in the Red Common directory.

Cons:

• Much manual labor: Many points of failure
• Scalability
• Maintainability (What happens when Nathan can't do it any more?)
• RR depends on FaQFiNDeR tool; what happens when it goes away?

Pros:

• Decentralized: Things work if one system goes away.
• Time Tested: It's been working, sort of, since late 20th century.

Our Proposed Method

How

This system will revolve around a collection of all the FAQsin one XML file. This file will also contain metadata about the faqs' age, owner, etc. The XML data will be transformed either nightly or by a given command into versions formatted for the web and the router accounts.

Other access and manipulation of the large FAQ file will be done through a perl module. This module will be used to create a web FAQ search, similar to the existing Faqfinder, as well as a Faq Administration web application.

The Faq Administration page will allow consultants to view/edit the FAQs they own, create/delete FAQs, and review FAQS which have been recently changed or created. The faqs which have been recnetly changed will be shown along side the old version (if applicable), and will not be entered into use until approved, either by a certain number of people or by some chosen Administrator.

This system should be running on the same physical machine as Router's Ref, as Router's ref will make calls to either the FAQ perl module or to the Web search cgi script.

Pros

• The xml format will allow for easy reformatting and presentation of the FAQS to whatever use is required.
• Meta data stored with FAQs will greatly reduce the number of outdated, orphaned FAQs.
• No more text files managed by hand. This reduces the time spent on faq management and the opportunity for errors.
• Router's ref will have a cleaner, more direct method of searching and categorizing FAQS.
• FAQ upkeep by consultants will be automated and on the web, which will make it easier and more pleasant for consultants to keep their FAQs up to date.

Cons

• If there grows to be a huge number of FAQS, the storage of the FAQS in a flat file will become a speed and efficency issue.