How Granular are your Spaces?

[Josh Wright]

So, I am trying to work out how best to structure content in Confluence and if we need to start splitting things out more. 

In the current & original structure we have created a team space for the IT Infrastructre Department, which contains all documentation for all Infrastructure related systems, project docs, KB articles and how to guides. 
This seemed to work well for a while and originally made sense. 

I am now wondering if we should be making better use of the spaces and move differnt systems to their own space. For example, have seperate spaces for VMware, SCCM, Exchange etc. and then general team space for generic KBs, how to guides etc.

The thinking would be if we had a project to move to Office 365, we would create a project space for that, which would then grow to contain tech documentation about design, how technical how-to guides and other Office 365 specific info. 

How does everyone else structure their spaces?
Do you just dump most things in one based on team?

[pb]

We use functional project areas.  For instance, we have a space for online community, one for offline (AUG) community, etc.  And the online community space is shared by our tech folks, the design folks, monique and I, etc.  But then, most of them also have another space that they work in with the rest of their team.

[Robert Reiner _smartics_]

Our spaces rely on index and attachment spaces for content reuse.

Index spaces provide space properties and description of commonly used metadata like categories or tags. Each of our spaces is attached to at least one index space.

Attachment spaces provide information relevant for more than one space such as libraries or address books.

What made it much easier for us using spaces is to differentiate between topic spaces and workspaces.

Topic spaces contain information that needs to be updated, like product or project information.

Workspaces contain records (like used in a diary or journal) that need not to be updated. Besides personal and team journals, we create workspaces frequently for spikes / researches on a given subject (used only by a small team for a short period of time, then archived or discarded). Handling new information as events in a journal removed the burden of many ad-hoc categorization disasters I produced in the past. The journal also removed many use cases that usually involved a topic space (all this I-probably-need-this-later-nonsense).

Having spaces for teams or products / projects works well for us. It sometimes proofed to be difficult to make spaces more fine granular. If you have a separate space for topic A and B, information that relates to both topics is difficult to manage. Team members need to decide where to store it, maybe add additional pages to ensure to find it in both locations. This drains concentration and slows down information flow.

That does not imply that we do not have spaces on different levels of granularity. For instance we have an introduction space for our product (the projectdoc Toolbox) and a manual for its current version. Information that is related (values, principles, and practices for documentation) is in its own space. Although all three spaces deal with documentation at different granularity, this is (usually) no problem since it is clear which information is stored in which space. On the other side I once decided to have a space for information related to security and one for e-government. Then I often encountered external information that applied to both subjects. Today all (we are a really tiny team) external information is stored in one attachment space and tagged. The topic spaces (security and e-government in this case) then select on information from the attachment space (by dynamic links and transclusion) using the provided metadata. So these spaces are merely entry points - plus information that is (from our subjective point of view) clearly related to only one subject. And this may still be a fault. Typically we try to store information on invariants and this is usually only the document type (a design document rarely morphs into meeting minutes) and the creation metadata: time, team/author it produced (that is a journal workspace), or the product/project it addresses (that is a topic space - installation instructions for product A rarely morph into instructions for product B).

Using Spaces provides an overview over the four types of spaces and provides some further information.

[Jim Craig]

Hi Guys, this is really helpful for me as with Robert we are a tiny team and are currently using Dropbox to manage (or not) documents. It's getting out of hand. I thought spaces would be a way to store different objects types, in a related and more contextual way.

I can't add too much to the debate as I've literally just started, and the customer facing stuff takes priority. What I can say is Josh, I was looking at things from a project point of view. Robert's structure, I feel, is a really well thought out approach to avoid duplicate effort.

Our aim is primarily document management.

[Robert Reiner _smartics_]

Thank you for you feedback!

The space type I struggle the most with is the topic space. I had a discussion with Bob Do on Should there be one or more spaces in Confluence?, but I am not sure if our approach works really well or if there are some use cases missing.

I'd love to hear what you will have come up with, what worked and where you still search for some improvement. Knowledge management is fun, but also tough. :)

[Jonathon_Prosper]

Hi there,

I split the domains or project, admin and operations in my space design.

In your instance (at a guess)

- Create "admin - <team>" spaces for each team. They can use this to create/maintain knowledge that is not specific to a project. Information such as team structure, purpose, goal, general info.

- Create "project - <product>" for each product. On the main landing page provide a basic oversight on all the major development items happenning in the products. Perhaps embed a jira macro with the epics and their descriptions and show a basic roamdap overview on the delivery timeframes for each. Then, create one page per major Epic of the project. In that page and under that page write up all your requirements pages, schreen mockups, business processes etc. Any information that helps the team "build the product" goes there. Dev teams would probably be looking at this content the most.

Finally

Create "Operations - <product>" or "Operations - <system(s)>". This space is dedicated to maintaining knowledge for the staff tasked with supporting the product post-release. This could include user documentation, common troubleshooting, release processes etc.

This kind of sructure at a high level has worked for me in the past. I hope it may be helpful.

JP 

[pb]

@Jonathon_Prosper, I rather like this structure.  Curious why you wouldn't collapse the project and operations spaces into the same one, perhaps with different areas within the space?

[Jonathon_Prosper]

It keeps the users isolated and allows the spaces to have a clearer unambiguous purpose. There is an atalssian video somewhere that talks about thinking of spaces as "rooms in a house". Each room has a purpose and you don't mix them together.

E.g. Operations spaces are for people that want the "right" answer about a topic. In other words, properly manage that content to ensure it is "correct". They want the confidence that when they punch in a search term for a space the content they read is accurate and up to date. Not "in-flight" versions of the truth that a project team are working on.

Project spaces are inherintly "transient" knowledge that may or may not be correct. It only exists to help a project team "build" something but ultimately it can be shut down and/or thrown in the bin once the project is finished. 

[Josh Wright]

Thank you all for the great feedback, I like a lot of the ideas here.