Inviting member groups to communities

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:

•      Workspace X is a community workspace, i.e. has community X as member.

•      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 work­space 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 commu­nity 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 ac­tion.

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 in­vite the community of the workspace instead, or if it has no community yet, to add a commu­nity with all members of the workspace in the standard role Member and invite this commu­nity.

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 con­sists of three subdepartments A, B and C, which in turn consist of some lower level orga­ni­za­tional 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 respec­tive 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 sub­department 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 unsatisfac­tory, you may want to transfer your existing organization from member groups to commu­ni­ties for better performance, which is relatively easy if you have followed standard practise 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’ col­umn 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’, ‘Mem­bers 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  | to community |  in the selection menu bar. 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 commu­nity A.

Instead of starting the process by adding an empty community to D and inviting the sub­department 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 selecting  | to community |  in the selection menu bar. This way, transferring a standard hierarchical orga­ni­zation 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 after­wards as well as you may turn workspace members having roles other than Member to com­mu­nity members manually.