Knowledge Base: Overarching Principles

  1. Clear and concise writing that is easy to understand
  2. Everything that can be publicly visible should be. See: Permissions and Visibility
  3. Don't recreate Google
    • If information is an easy Google search away, think carefully about whether we need to also maintain that information in our own KB
  4. Don't recreate vendor support sites
    • Link out to vendor support whenever possible rather than duplicating their content into our KB (and then having to maintain the duplicate content)
  5. We DO want to provide curated, local, current information about how technological things work at Carleton with Carleton Systems for Carleton People.
    • Outdated information clutters result lists, so we'll delete or archive information that isn't current
  6. Build articles as needed, and then refine articles as we go
    1. Find It!
      Always search the KB when working on a ticket
    2. Flag It!
      If you find a relevant KB article, say whether it was useful and up-to-date or not
    3. Fix It!
      If you know how to improve the article, edit it and submit your draft for review
    4. Add It!
      Didn't find an article you needed? Start one and submit it for review, even if it's just a stub
  7. Attach KB articles to Tickets whenever possible
  8. Pay attention to and respond to feedback on articles so that we constantly refine our content
Was this helpful?
0 reviews
Print Article

Related Articles (1)

ITS Knowledge Base Style Guide: Quick Start Guide
Overarching principles for Knowledge Base articles, plus specific decisions about naming conventions, use of images, etc that will help our Knowledge Base look consistent and predictable to our community.