It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Looking for a standard initial structure for some wiki spaces

Our wiki has gotten a little out of hand, as part of this I've tasked my team with coming up with a better way to manage and maintain the content that is in the wiki.

We're an IT development department and as such we've determined that we will have three types of spaces:

  • Team (general stuff for the team, leave register using Team Calendars, org structure etc)
  • Project (short lived information relating to a project; purpose, incomplete documents, tracking expenses etc)
  • System (each application will have a space, this would have everything about the app, architecture, design, operations, support etc)

Currently we're very project-centric therefore information about a system will tend to be in lots of different spaces (depending on how many projects have been involved in that system). This makes it dfficult to see what is the latest version and to even find the info.

Has anyone done anything similar? Did you come up with similar space types to us?

My main question... what did you use as the base hierarcy under each of these types of spaces?


2 answers

1 accepted

1 vote
Answer accepted

Here are the instructions we developed for a space "spring cleaning" exercise a few years ago:

Skip to end of metadata
Go to start of metadata

The COOR Team is increasingly concerned that it is hard to find things on our wiki space.

I believe this is a fundamental issue with wikis. Successful wikis grow quickly and organizational paradigms that work at one information volume and participant pool may not be adequate with significantly more volume or participants. In the global wiki community there are frequent references to "wiki spring cleaning" and I think spring cleaning probably needs to be an annual exercise, at least for our space, given our current use patterns.

Suggested Approach

Scope and Scale


I drafted this for the purpose of "spring cleaning" the EDM space. My previous experience with spring cleaning was with the eLandings wiki, which at that time had about 2,000 pages in a handful of spaces, with about a dozen active contributors. I am proposing using approximately the same process for the EDM space, which I believe to be substantially similar in size. (I can't confirm without installing a statistics plugin.) I am sure there is some size threshold at which this process would become ineffective, but I don't think the EDM space has reached that threshold.

I propose that we do a little preparation and then schedule a wiki spring cleaning conference call, and that the major space cleaning happen during the course of the conference call. (It sounds a bit chaotic, but, I have used this approach once before and it worked that time!)

The preparation consists of a review of the existing space content and appropriate seeding of the wiki to suggest a high-level organizational framework for the existing content. The proposed new spaces and framework pages should be labeled "proposed" to make them easy to identify. The new proposed spaces and pages should be left as empty placeholders. Don't obsess over the proposed framework, as it should be obvious that the proposal is just a starting point for group discussion, and not an adopted solution. Links in the Resources section below provide guidance that we should consider while building the proposed framework. Note that in a reorganization-in-place, proposed new framework components will be mixed with existing components that already reflect the inherent structure of existing content. Alternatively, there may be a proposed set of new spaces and framework with expectation that all valuable content be moved into new structures.

The conference call should be open to all the active wiki participants, although we should only expect a few of the most committed contributors to show up. Five to ten teleconference participants would be a good balance between "many hands make light work" and the chaos of a large teleconference. Background material (such as this page) should be distributed in advance so that collaborative air-time doesn't have to be spent presenting identical information to each participant. A session secretary should be designated in advance and should lurk on the call to record significant decisions. The call should start by confirming that each participant on the call is logged in, in the right space, and has windows open to both the Browse Space - List Pages - Tree View and the Browse Space - Labels - Popular Labels .

The spring cleaning leader can then lead a discussion of the proposed framework, starting with the highest organizational levels (spaces) and presenting the proposed topic and subtopic pages. If consensus agreement on the highest organizational levels can be reached with minimal discussion, then each of those major levels should be assigned to sub-groups of participants, and those sub-groups should start moving, renaming and labeling pages. And perhaps most importantly, pages which appear to be duplicates or orphans should be removed or moved to the authors personal space. Participants should speak up to share newly minted naming conventions, new labels, improvements to the proposed framework, or controversial page removals. The leader can call the group to order periodically to check on progress and solicit group discussion around the emerging structure.

As new naming conventions and labels surface the designated session secretary should record them. Some new documentation will emerge from the revised site itself and won't need to be specifically published, but rough notes should be kept because some on-the-spot decisions should be permanently recorded in our Wiki Governance or How to Use our Wiki documentation.

After a significant period of productive spring cleaning, the group may decide to abandon the teleconference format and proceed individually with more detailed work, or, they may want to schedule another session, or they may find their task complete.

At the end of the process the pages labeled "proposed" should be revisited, and the pages should be removed if they were not used, or relabeled, until there are no more pages labeled "proposed". The session secretary's notes should be reviewed to decide which need to be published and in what form. And finally the process and outcome should be reviewed for lessons learned, as it seems likely that this process will be needed again.


In preparation for spring cleaning I have been looking for guidance online, and I am accumulating relevant links as delicious tags at:

Here are links to some of the most germane spring cleaning guidance:


<h6>Unsure How to Label?</h6>
  • Author names are not useful labels
  • Meeting Pages - When creating labels, keep in mind how someone will search for the information. Be consistent and specific in your label choices. An example would be labeling meeting minutes:
      • meeting_minutes
      • meeting_agenda
      • [agenda name]_meeting_minutes
      • year
      • [page label]_meeting_minutes
<h6>Removing "Trash"</h6>

Pages within the "trash" space are still available for query. Any user can remove a page within the "trash" space. Once a page has been removed from the "trash" space, only a space administrator can permanently remove from the wiki or restore.

Prior to removing a page, it is recommended to review the incoming links.


When working with parent pages, remember to review the child pages. Taking the same level of effort to organize the child pages.

  • Consider how to update the Terms of Use page.

Having nutured a few wiki instances for a few years, I have come to the opinion that wikis just require restructuring every year or two. Structures that make perfect sense for a few hundred pages just don't make good sense for tens of thousands of pages, and when page counts get to the hundreds of thousands, structural requirements are likely to be different again.

What has worked for me a couple of times is collaborative "spring cleaning", often with several of the most engaged participants sitting in front of their own comptuters but in voice contact via teleconference, and dividing up the work. I usually do some homework first and try to determine what parts of the structure are still working well, where the biggest need for improvement is, and creating some new spaces and top-level pages and/or labels as examples/guides. Then everyone on the phone takes on some section, and they create container pages, move content around, do some re-titleing and labeling if necessary, and in the course of an hour a new structure emerges that is a better fit for the material currently in the wiki.

But in my experience you will have to do it again in a year or two.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Thursday in Confluence

Confluence CVEs and common questions

Two vulnerabilities have been published for Confluence Server and Data Center recently: March 20, 2019 CVE-2019-3395 / CVE-2019-3396 April 17, 2019 CVE-2019-3398 The goal of this article is...

197 views 0 11
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you