Groups Feature Improvement Suggestions

The Groups feature is a potentially powerful and useful thing, but right now it has some serious limitations which I know are being worked on. (Sorry If I'm covering already discussed stuff.)

We should certainly be able to be members of far more than 15 groups... however the categories of these groups need to be distinct so that they are used in different ways. Here are the following "types" or "uses" of groups we need to be able to set in some sort of Groups Configuration window or dialog box. (Honestly, I hope that some day the dialog boxes and the Inventory system can become a PDA or Laptop computer object that our avatar caries around.)

1) Groups intended for sending and recieving conversation from people connected to SL at the moment (I know, it's already implimented - I'm simply mentioning it as an example of a distinct use of a group membership)

2) Groups intended for messages that EVERYONE in the group sees, whether conected or not (these should go to a special INBOX, for group announcements. We should not have to use the voting feature for this as people do now. We should also have the option of being able to recieve messages of this type from a specific group even if we do not want to recieve other communications from Second Life externally - and these messages should be able to reach us as email or as SMS text messages on a cell phone or other device.)

3) Groups intended to give permission to a person to enter (or be blocked from) an entire sim, an area within a sim owned by a specific person (patch of land), or a specific area (like a building) inside a patch of land. This also means that sounds and cameras can be blocked for entering such an area or seeing from far away what is going on inside that area if the windows are blocked or one-way. (It should not be possible to spy on people with invisible cameras or with moving an avatar through a wall by moving an edited object through the wall while sittingon it - if the person who owns that area specifically has requested this not be possible or a program blocks this type of thing.)

4) Groups intended to give different levels of administrative control and building privileges in an area. This also means that the a number and type of things people can or cannot do as members of such group should be configurable on a person-by person basis as well as for the entire group.

5) Groups intended for fraternal membership in some assocation - like people who frequent a casino, members of an army, fans of someone or something, political activist groups, etc. (This generally is the group type which should be part of the option of having a name/label floating above your head. Other types of group are not neccesarily going to be used for such.)

6) Groups that allow a person to be affected (or not affected) by specific effects of specific scripts/programs, such as weapons or simulations of some kind (like illusions, hallucinations, dreams, time travel (in which past events from a specific location are replayed), visual tutorials and teaching guides (we might have some sort of visual 3D animation intended to teach someone how to do something, but it may be intended for only one person to visualize), etc.)

If anyone has other ideas for group types, please mention them in a followup message.

Group limit will be raised to 25 with the release of 1.12.0.1

What would be the usefulness in having each group belong to a 'catagory'? Why not just use the group charter field to put information about what the group is for in that?



Group newsletters will become possible when 1.12.0.1 is released.
With regard to recieving newsletters from a specific group via email/etc... that sounds like a reasonable idea, though if you want coders to spend time on it you will have to come up with examples demonstrating how it is important enough to justify priority over the other work they're doing.



Personally I think the don't render inaccessible parcels for people who can't go there, possibly implemented as a checkbox for parcels (if on, don't allow people who can't go here to see anything on this parcel, even with alt-zoom etc), is a better solution for this then groups... as it is simpler.


See the group roles system.

Many people use, say, 'land owning' groups that run to give themselves custom titles. Would you want to discourage this?

Permissions of what can be done to an avatar on a certain bit of land should be set by the land owner or group settings of the group that gives them access to the parcel.
General settings for what can be done to an avatar belong in the SL client's preferences box, as that way they are always accessible to the user, are integrated with the other client options, don't require a group slot and don't make your preferences public.
If we had to join a group to be vulnurable to outside push.... imagine griefers joining this group and using it to search for people to grief.... bad idea. Let client settings be done in the preferences/options screen, not via a group.


Overall, I think your idea for categorising groups might be useful, but so far you haven't shown via examples that it would be useful enough to justify making it a priority for the SL coders.

I didn't mean to suggest completely different categories but some way to understand and impliment the completely different uses of groups. You could have a "Group Configuration" dialog box in which all the groups you are a member of are listed and you set attributes on them. I was just trying to explain an idea, but I didn't do enough to explain it.

In some cases there are group types, or attributes, that 15 or 25 max memberships are just too low, because of the fundamentally different uses of groups.

I think the ability to avoid push weapons or other griefer abilities is separate from using a group to deal with specific effects of some programs. The point was to have one more option for regulating how people are affected by things in SL.

In general, I do think we want to weigh the fact that the interests of people who want to reach-out to others are different from those who want to be totally private, and there need to be compromises because of this. I don't think an adjascent sim should be un-rezzed (why not make it a remote island instead?) unless this is a very specific (and rarely used) setting, and even then, it seems to defeat the purpose of Second Life. I would much prefer that closed or locked buildings were more secure and private than they are now.

Someone suggested making it impossible to see someone's green dot if you chose not to in some settings. But if they are in the same map area with you I don't see why they shouldn't be able to see your dot. Just because they know *someone* is inside a building, if there is no way for them to harass you inside that building or even know your identity, then that should be enough. It is reasuring to at least see that someone is there in a sim, even if they don't want you to bother them.

I think we want to remember that what makes virtual reality best (like in cartoons) is the ability to bend rules, but rarely break them... lest it all become just too easy and boring, or so unrealistic it's not interesting anymore. Of course if the majority of SL members want it, then go ahead with it.

From : another forum topic :


About the different uses of groups - with the group roles system, you can just assign permissions and settings differently, and you have no problem with different uses of groups.