Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,410,888
Community Members
 
Community Events
169
Community Groups

How do you structure your page trees for internal knowledge bases for processes or software?

I'm always curious how other people decide to design their knowledge base page trees. Ideally, it would make sense to both technical and non-technical viewers (even if they don't always all of the content like database schemes, etc).

For more complex projects we use something similar to this:

  • Team & Communication - This is an overview of the project
  • Development - different pages for test data, system architecture, new dev guides/resouces, dev/uat/stg/prod infrastructure, integration points, 3rd party components, etc.
  • Meeting Notes - internal/external meetings related to the project
  • Project Management - estimations, project plans, etc
  • Quality Assurance - overviews of qa environments, reports, testing plans, etc
  • Requirements - Technical requirements for the application; This is where most of the content lives. 
  • Retrospectives - mostly meeting notes from the dev team
  • Trackers - decisions, change requests, glossaries, dictionaires, external documents, scheduled tasks, etc.

For less complex projects we use something like this (adapted from this article):

  • 00 - About - General introduction and overview of the project, team and communications
  • 01 - Roadmap - All things related to planning and specifications. This is the main working area for the analysts and will contain things like backlogs, wishlists, functional specs for a future version etc. This is the main area where you will find the actual projects.
  • 02 - Development - Groups everything that someone needs to know to be able to develop on the application. Note that a technical analysis for a specific story to be implemented does not belong here, a technical overview of how something is implemented does.
  • 04 - Release Notes - This section gives an overview of the entire release history.
  • 05 - Maintenance & Support - This section groups all documentation relevant for operational (technical) support of the Knowledge Base. Ideally, this is enough so a team member without knowledge of the inner workings can offer basic support (like editing articles, check log files, etc).
  • 06 - User Documentation - Contains all end-user documentation like manuals or public API's.

Just curious how those more experienced handles this and I'm looking for ideas and best practices we should start following. 

1 comment

Hi! Thanks for your post in listing your internal page structure. I was looking for best practice examples. One or our requirements building out the below table of contents was that it would be designed for technical and non technical team members to be able to navigate. Here is a navigation tree I developed with my team in my last company.

It was a challenge managing it as we grew, as the laws of entropy strike first in documentation and there are always other tasks that seem more important than playing a librarian - though it was worth it for our team.

* Introduction

* Onboarding Overview

* Training

* Teams

* Ceremonies & Meetings

* Initiatives & Projects

* Process and Procedures

* Testing

* Release Management

* Production Support

* Business Capabilities And Tech Components

* Terminology

* Miscellaneous

* Confluence Feedback

* Product Refinement Process

* Ideas for Machine Learning

* SRE

* L1/L2 Production Support How-to articles

* Platform Applications

* Product Strategy

* Run Books

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events