This issue was the cause of many long discussions and debates internally. Its almost a perfect 50/50 split of which behavior people prefer. I will try to briefly summarize why we made this switch and how you can think of forums in terms of spaces.
If a space aggregates together all content from all of its sub spaces, the content created in that space quickly gets lost. For example, if I have a Development space, which has ten subspaces for each of our development products, a document explaining development policies, or an engineering question posted to the entire development community will quickly become pushed out by all the activity happening below the Development space. Since I work specifically on the Clearspace product, I'm not interested in the day to day activity of the other nine products, so making the development space a roll up of them all essentially makes that space worthless. Also, there is a definite performance gain of not rolling up content from all the sub spaces. Whenever any change happens in one of the sub spaces, it has to destroy the query cache of every parent space. There are some other options like page level caches that can alleviate this problem (if it becomes one), but having this as a side effect is worth noting.
All that being said, we still have the option in our API to get a roll up of all content from all subspaces for a particular space. It would be a pretty minor customization to change the behavior of the application. With the external edition of Clearspace coming out soon, we might get more requests for a roll up of content. If so, I'm pretty confident we could make a simple admin console switch to make this happen.
As far as thinking of spaces vs forums, they are essentially the same thing. They both have permissions, contain content, and define the structure of your community. The difference is that in Forums, you had both Categories and Forums, where forums were essentially the end node of the category tree and contained all the content. In Clearspace, you only have one object, a Space, which can contain content and also have sub spaces.
Except now you have tag groups, which may or may not replace some
forums/subspaces. And tags are findable across all Spaces. All of this has
given us some head scratching as we re-map our conceptual models.
Also, there's the old problem you used to see in Usenet -- some people would
post to the parent alt.topic while others would post to alt.topic.misc.
Maybe we could use the parent space for admin/news posting, and let users
only post to the subspaces -- this would be more in line with what our
current forum users are used to (again, focused on xpace only).
You might have already seen this, but for a detailed description of the difference between spaces and tag groups, check out the following message:
Hope it helps sort out the confusion a little.
Nick, thanks, that was useful. We'll be talking with you more directly about this, but for everyone else, here's the dilemma.
A Space still has features & UI & state that a tag does not. Our users are used to forums mostly divided by product. Here's an example of <a href="http://www.vmware.com/community/category.jspa?categoryID=90">our busiest category</a>, divided by products and features in the suite. Ideally, you'd make all these 8 forums each a tag group, because it's the same group of people who use all of them.
Looks like 150 threads have been updated over the last 24 hours in those 8 forums. With that much traffic, I worry that going to the Space & then filtering by tag group is going to be harder and overwhelming than just going to a Subspace. Each time you switch content type you lose your filter. If you click back to the main Space instead of using your back button you lose your filter. It seems like it'd be hard to keep track of what you were scanning and just feels much more precarious than a separate Space.
So perhaps volume is another reason to split content into Subspaces.
moved to a new thread **