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

Many small spaces or a few large spaces

nmosher-aafp

We're working on a project to bring some organization to the chaos that is our confluence instance right now. We're focused on the IT department and have an idea to have just 4 spaces: Projects, Teams, Products, and Vendors. This would mean that the projects and teams spaces are likely going to get pretty massive. I'm concerned that this might create issues with the database and/or the ability to find stuff.

Alternatively, we are considering making categories for those for items (Projects, Teams, Products, and Vendors) and letting each sub-item be a space on their own. We could then have a main space called IT Dept that would have links to each of these spaces to provide a sort of home page for the whole thing. I'm concerned that this model will get out of hand and we'll have way too many spaces to manage effectively.

Do any of you have any preferences to these two models? Any tips before we get started?

Thanks, Nick

Comments

Robert Reiner _smartics_

Unfortunately there is no easy answer to this. ;-)

Spaces encapsulate pages. There are tools provided by Confluence that are space-related (for instance permissions and index pages). Therefore I'd favor more spaces over fewer spaces. But a lot of almost empty spaces is certainly also a problem for users to find information. So in the end the decision has to be based on semantics, cohesiveness and encapsulation, ...

Fortunately there are already discussions on the granularity of spaces in the community. For instance:

Maybe this helps as a starting point?

It would be great if you would share what you have decided and why ...

nmosher-aafp

It looks like pretty much everyone recommends smaller spaces in my case. Thanks for providing those links. I was having a hard time finding information on this topic.

Bill Rudy

We're also grappling with this. My initial feeling is to press for fewer spaces (we have a contingent just itching to go "space-happy") as it just creates more to manage and more chefs in the pot admin-wise...and can quickly become an organizational mess...but still weighing the pros and cons of more vs less. In my particular dept, we have a roughly one space per team, with a few other spaces for various stand-alone things (like one for software releases, one for a major ongoing program etc). Would love to hear from others and lessons learned.

nmosher-aafp

Our adhoc world has created a bunch of spaces, many of which are not used anymore. We also have a major problem in that people don't know where to put things. I THINK it would help to have fewer spaces but I hear the arguments about restriction nightmares as well.

My team is considering a hybrid approach now. We would have limited pages for long term items like teams, divisions, and products. Projects would become their own spaces with an 'index space' that catalogs all the projects.

Seems like a good compromise but we are going to explore it a bit first.

Anyone else have thoughts on the subject?

Kelly Albrecht _Western Massachusetts_

Something that has been the most important for my teams in my experience has been notifications and watching. For example, some roles like to watch a whole space, but they also don't want to be flooded with updates that don't concern them. So a good strategy has been start with fewer larger spaces and if a section of a space starts gaining a life of its own and gets noisy, then we consider moving that section into its own space.

I like to start with larger spaces to avoid too much siloing, but continuously improve the arrangement by giving sections their own spaces if they are using Confluence heavily enough.

This works really well for small to midsize teams, but I think it scales fine. It's a fun challenge to think about!

Robert Reiner _smartics_

From my point of view there are (at least) two questions to control the number of spaces:

Is there a stakeholder / team caring for the existence of a particular space?
Does everyone know where to add / find information (is there a natural single source location)?

I made the mistake to add spaces for topics (like security, performance, or tools), but it got troublesome to place information that is related to more than one topic (e.g. security and performance). So in this respect fewer is better. Define the location for pages by invariants (which in our case is mostly the type of 'page'). Then add views (e.g. lists by label) on pages for different audiences.

We have collected values, principles, and practices in Agile Documentation on our site to cover what works for our technical communication.

Larry Wilson

I like many spaces but at least one team can't get their heads around it ...

I find using the properties macros and labels and enforcing templates for page types helps to generate indices that can organize pages either way ...

It ends up allowing JQL type queries for listing pages ...

Of course topics work too, they also should be part of the Page template ...

I do encourage spaces to have Knowledge Base types with Templates for the pages underneath ... but barring that ... I encourage page "Containers" that have a button for creating the correct page template for subordinate information.

One other note: I find it easier to recover a removal of a full Page Hierarchy than a Space deletion,...

But, all in all, Page Templates and common change control for Labels and Template identities...

Regards

Welcome!

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

Quick Links

Find more posts tagged with

confluence

server

confluence-server

space

team

organization

architecture