The effect of inviting the member group of a workspace X to a community Y is still more surprising. We have to distinguish two cases:
o Workspace X is a community workspace, i.e. has community X as member.
o Workspace X is not a community workspace.
Case 1: When you invite the member group of a community workspace X to a community Y, community X (and not the member group) becomes a member of community Y, i.e. becomes a subcommunity of Y. Members of community X can access community workspace Y in the community role of Y, while other members of the community workspace X have to become also members of the community X to access the community workspace Y. Community workspace Y does not become contained in community workspace X by this action in spite of community X being a subcommunity of Y.
Case 2: When you invite the member group of a workspace X, which has not yet a community as member, to a community Y, a hidden community is added to X with community role Member, all members of X with this role are transferred as members to the new community X, and the new community becomes a member of community Y. Consequently, all members of workspace X in the role Member can afterwards access the community workspace Y as members of community X, other members cannot unless they are also members of Y. Again, community workspace Y does not become contained in community workspace X by this action.
The member group of a workspace cannot become a direct member of a community because the potentially different roles of the members of a workspace member group would violate the community concept of many members with the same role. So, when a member group of a workspace is invited to a community, the next best solution to forbidding this action is to invite the community of the workspace instead, or if it has no community yet, to add a community with all members of the workspace in the standard role Member and invite this community.
Note that the same procedure is applied when a community is created with member groups as initial members: not the member groups become members, but the communities of their workspaces, or if they have no communities yet, communities are added to the workspaces which become members.
The latter mechanism supports the transfer of a hierarchical organization of member groups to the same organization with communities, which is especially useful when the member groups have become too large. We will use the department example from above, where department D consists of three subdepartments A, B and C, which in turn consist of some lower level organizational units. If you want to map this hierarchical organization onto BSCW workspaces and the associated member groups you could proceed as follows:
• Create workspaces for the department, the subdepartments and the lower level units.
• Invite the users belonging to the lower level units to the respective unit workspaces and add the member groups of these unit workspaces to your address book.
• Invite the member groups of the lower level units to the subdepartment workspaces and then the member groups of the subdepartments to the department workspace.
This process results in a hierarchical organization of the member groups: member groups of a lower level in the hierarchy are members of member groups one level higher. For the respective workspaces the relation is the other way round: a higher level workspace is contained in workspaces one level lower in the hierarchy. Thus a member of a workspace lower in the hierarchy has access to all workspaces higher in the hierarchy belonging to the path leading from the workspace to the top of the hierarchy. Take as an example unit X belonging to subdepartment A: a member of X has access to the workspaces A and D because D is contained in A which in turn is contained in X.
When your member groups have become too large and response time has become unsatisfactory, you may want to transfer your existing organization from member groups to communities for better performance, which is relatively easy if you have followed standard practice and assigned the default role Member to all ordinary members of your workspaces. This is how you should proceed:
• Add a hidden community to department workspace D via Access Add Community in the action menu of the workspace. As community role you choose Member. The new community is initially empty.
• Go to the members’ page of D by clicking on the icon shown in the ‘Share’ column of the community workspace entry. The members’ page shows the entries for the new community D and the groups of the three subdepartments ‘Members of A’, ‘Members of B’ and ‘Members of C’ (and in addition your own entry as manager and perhaps some other staff).
• Invite the three member groups by ticking their check boxes and clicking in the multi-selection toolbar. This creates three communities A, B and C with the members of the workspaces A, B and C in role Member. These communities become members of community D.
• The lower level organizational units are converted automatically to communities since their member groups recursively become the initial members of communities created on the fly. Take as an example two units X and Y belonging to subdepartment A. When community A is created, its initial members are the member groups of X and Y. Consequently, communities are added to the workspaces X and Y with the members of X and Y in the role Member, and these communities become members of community A.
Instead of starting the process by adding an empty community to D and inviting the subdepartment member groups to this community, you could have gone to the members’ page of D right away and could have created the community D with the initial members ‘Members of A’, ‘Members of B’, and ‘Members of C’ by ticking their check boxes and clicking in the multi-selection toolbar. This way, transferring a standard hierarchical organization of member groups to communities becomes in fact a one-shot process. Of course you may fine-tune community roles and admission policies of some of the communities afterwards as well as you may turn workspace members having roles other than Member to community members manually.
Note: The transformation of a hierarchical organization of member groups and their workspaces to communities as described above lets the workspaces involved lose their original inclusion relations; access to higher level workspaces is enabled via the hierarchical community organization and not via inclusion relations between the workspaces. This has the consequence that all workspace members in roles other than Member lose access to higher level workspaces because they are not automatically turned into members of their workspace community.