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? Thanks!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Looking for a standard initial structure for some wiki spaces

Graham Rivers-B

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?

Thanks!

Accepted answers

Larry Talley

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

Wiki Space Spring Cleaning

Skip to end of metadata

Added by Larry Talley (admin), last edited by April Wolstencroft on Oct 08, 2010 (view change)
show comment

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

Icon

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.

Resources

In preparation for spring cleaning I have been looking for guidance online, and I am accumulating relevant links as delicious tags at: http://delicious.com/ltalley/wikispringcleaning

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

EditMe's Wiki Gardening
possibility.com's HowToOrganizeWiki
Brown University's Wiki Review Taskforce
MAX Federal Community's ¿Organization of Pages (requires MAX Federal Community login)

Notes

<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.

<h6>Pages</h6>

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

<h6>Follow-up</h6>

Consider how to update the Terms of Use page.

All comments

Larry Talley

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.

Larry Talley

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

Wiki Space Spring Cleaning

Skip to end of metadata

Added by Larry Talley (admin), last edited by April Wolstencroft on Oct 08, 2010 (view change)
show comment

Go to start of metadata

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

Suggested Approach

Scope and Scale

Icon

Resources

In preparation for spring cleaning I have been looking for guidance online, and I am accumulating relevant links as delicious tags at: http://delicious.com/ltalley/wikispringcleaning

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

EditMe's Wiki Gardening
possibility.com's HowToOrganizeWiki
Brown University's Wiki Review Taskforce
MAX Federal Community's ¿Organization of Pages (requires MAX Federal Community login)

Notes

<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>

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

<h6>Pages</h6>

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

<h6>Follow-up</h6>

Consider how to update the Terms of Use page.

stpl

I can se you have a wiki governance, and i'm starting to write one to. Can i ask which topic do you Larry have in yours?

Larry Talley

I understand the question but I'm no longer the right person to answer that. I am not currently active in our wiki governance. And I don't want to post other people's email addresses in this public forum. But I will post mine, larry.talley@noaa.gov. If you wish to communicate with me directly I can then forward your question to people in my agency who are currently involved in wiki governance.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

confluence-administration