06-15-2005 06:28
One functionality-limiting aspect of groups as they exist in SL has to be their flat nature, i.e. the inability to use them for an organizational hierarchy.

For example, consider the groups that might be necessary to properly run a multi-use estate sim:
  1. group for landowners
  2. group for residential rentals
  3. group for retail rentals
  4. group(s) for event notifications
  5. group(s) for event venue(s)
  6. group for event hosts
Each group has a specific function, and targets specific members. However, the leadership of all of these groups would come from a core subset of individuals, and the higher up the ladder they are, the more of these groups in the hierarchy they would have to belong to in order to maintain any sort of administrative or managerial control.

There is no ease of communication. If a message needs to go out about an event, let's say: it would need to be posted to the 3 types of event groups separately. And if any members belong more than one of the event groups, that message just gained the honor of becoming event spam!

Currently, work-arounds exist but they are by no means solutions:
  1. If you are running low on groups, create an alt for the excess. But that dilutes the individual if they must now communication through two different personas. This would be more necessary, but less desirable, the higher up you are in the hierarchy.
  2. To communicate to multiple groups, cut and paste is your friend. But you still have to open each group and then remember which of the groups you had already sent the message.
I propose that groups be allowed to affliate (become members of) other groups so that they can share resources, membership, and lines of communication. Using the example above, the groups could be arranged in levels: the Landowner would be the top level; under Landowner would be two groups: Rentals and Events. Under Rentals would be Residential and Retail subgroups. Under Event Notifications might be Venues and Hosts.

In this hierarchy, a message sent to Event Notifications would also go to the officers and members of the Venues and Hosts groups.

This would protect the group land by limiting sale to officers in the Landowners group, but allowing the officers of downstream groups to use the land tools.

Additional functionality:
  1. Toggle for messages to be sent to only the current group or all subgroups by officers. Members would be limited to sending to their own group, not the subgroups.
  2. Addition of a toggle to refine what an officer in a particular group is capable of doing downstream.
  3. Addition of administrative tools to enhance or limit the resource use of downstream groups.
  4. Prevention of looping groups by assigning and limiting affiliate levels.