This issue is now resolved in the latest version of Confluence Questions.

A global "Questions" Plugin is definitly not Enterprise, i mean, if you host more projects in your confluence, with different users, Q&A can have the same questions but different Answers.

I mean for example

"Who is the project leader?

Answer a) Mr. Foo (for project/Space "Infrastructure")
Answer b) Mr. Bar (for project/Space "Billing")

But the users inside Space Billing are not allowed to see the users/Questions from the "Billing" Space, because of data/privacy restrictions and so on.

So +1 for "Allow questions to be associated with a space"

+1 to limit questions (or topics) by the spaces.
Correctly asked questions contains half the answer. More often than not a person asking a question already knows where the answer might come from.

I agree that I'd like questions to be scoped per space, but I don't think it will ever happen now.

My understanding is that Confluence's existing content capability is thought of as the product "Confluence Spaces", whereas Confluence Questions is positioned as a separate product "Confluence Questions".

So perhaps one day it'll be possible to use Confluence Questions without buying the Spaces part of the platform.

I agree with many here. Essentially:

• Global questions quickly fill up to a level of "noise" that could potentially make it less attractive as a solution
• One question could be answered differently, depending on the group. (Consider a question "how do I build the software?". The Java guys and .NET guys have different answers, as could other teams throughout a segment.)
• There could be legitimate issues where sensitive information shouldn't be presented to "the whole company", yet for specific groups it's highly useful for them to have quick access to such answers. I think this is what @Sridhar was thinking, too.

Allow Questions to be added to space and use the Questions permissions to provide access to users/group. This ensures that Questions add-on is visible only to users/ groups with permissions within the space.
If an user has access to multiple spaces, ensure that topics created in a space does not span across other spaces when users with multiple space permissions view Topics.

@Bob, it's a bit of a square hole and a round peg, root cause is not security, but design and security should not be used to force design (integrity) restrictions (if it can be avoided; since it is an extra and complex layer).

The design needs to be clarified and it needs to be confirmed if (a) questions can be considered (or can contain useful) content and (b) if confluence organizes content into spaces.

An important factor in this is permissions. You may want to segment questions based on permissions. Since permissions are at the space level, then restricting by space would accomplish that. I suppose you could also consider question restrictions just like page restrictions. Another use case is organizing questions by a group of spaces (category?) although that makes the permission thing more complicated.

+1 (again)

Situation: There are multiple teams in the organization and each team has a space. All the teams have installed Questions and now they have created Topics as per their needs.
Now there are:
=> Multiple topics and the numbers are growing as teams install Questions Add-on.
=> In the Topics tab, the topics created by all the teams are visible (Other department topics appear as well)
=> Topic naming conflicts with other teams exist since certain teams have created Topics that you require for your team (Early bird gets the topic name).
=> So with little choice, we agree to use the same topic and be on the watcher list, there are many irrelevant questions that come as part of the topic that are not work-specific

Advantage of Questions being Space-specific:

=> Discussions limited to only specific teams (Administration need not know what's happening in Research)
=> Create multiple Topics and organize better
=> View only team-related topics
=> Manage/Moderate easily since it's space-specific

Just my 2 cents!

Thanks
Sridhar