More premium incentive is always good

I am elaborating more for the convenience of the linden that reviews this so it can be implemented as easily as possible.

I would gladly pay to hold more groups.

Current groups have to store a bunch of data on who is in what role, what the roles are, what the abilities are, etc.

As one example of such a limited purpose membership entity, a chatstream membership entity could have one or two ranks of officer, with one ability, to expel and ban members. No need to store anything about group land because the group wouldn't be able to own land, no need to store any data about group funds because the group wouldn't be able to engage in any financial transactions. The only thing the group would be for would be to chat. Such a group would be fine for product announcements. Chat for such groups would be sent through a different means than normal group chat is sent. Possibly the chat would actually be done by a server provided by the group, leaving SL servers free from the burden of transmitting the chat text. Something along the lines of an IRC channel, displayed in a in-viewer mozilla browser window, or from a normal web browser or IRC client.

Individuals belong to many more that 25 sets, and the sets they belong to aren't all the same type of set. LL needs to figure out some way to deal with this fact and represent our belonging to many different sets of different types in SL.

for people that have vendors in many differnt sims like myself and most of them needing
you to be in a group 25 isnt nearly enough, im constantly dropping groups to join new ones

this would leave a LOT of room for other types of groups, then. Social groups, and discussion groups.

Imagine that you're walking across the landscape. At each pixel you move, the system has to check the following:

• if you're entering a parcel that is limited to a specific group, and you're in that group, and have an appropriate role
• if you're being 'sensed' by a device that only works for group members

This happens for every pixel you walk. Now apparently this causes a huge load on the database. Notice that my description is probably very unaccurate, since the system very likely caches locally all group information for all parcels and objects in that sim. Still, all movement needs to look group membership up "all the time".

On top of that, group membership (specially in the large groups) mean that every time an IM is sent to a group chat, the system needs to check who is in that group and who is online, to set up the proper communications to the correct avatars. So this is an extra order of complexity.

Now, SL has evolved, and maybe the system is not so "constrained" any more, but this was the reason given when the group number changed from 10 to 15, and later to 25: basically, it's not so easy as wayfinder tends to infer, and yes, under the current implementation, 5 or 500 groups makes a HUGE difference (since the required computation does not rise linearly, but exponentially...).

On the other hand, SuezanneC has brought up the old argument we always had: make groups simpler, eg. "spam groups" that will give you a title, but not ownership of either objects and/or land. They'd be simply used to keep in touch with people — and could in theory be unlimited in number!

Right now, just upping it to 35 or 40 would be a great help.

500 wd be too many...but it shd be at least 3 or 4 dozen rather than 2 dozen.

@SuezanneC Baskerville, re: creation of simpler group-like entities which cause less DB load
Great idea!
Most groups are not used for land-related tasks.
Rather, they are used for group chat and notices, as well as the odd title.
Why not have a simpler, group-like structure which omits the functions that most groups don't use, and thereby, takes up less database/network resources? It could be called an "association" or something similar. Converting groups which don't use land/L$ functions into "associations" could save server resources, thus providing the free capacity for us to be members of more groups/associations.
In particular :

• Association memberships would not be checked when determining access permissions on parcels
• Associations would not be able to take L$ from their members, or be paid L$.
  It could all be seamless to the user, as well:
• All groups, when first created, start off as associations. The group creator is charged only L$50 to create an association.
• Full Groups are converted to Associations when they have had no L$ activity for the last month, and do not have any land set or deeded to them.
• Associations are converted to full groups when land is set or deeded to them, or when an object is deeded to them. Converting an association into a full group costs the person who does it L$50.

The potential problems I see with this idea are :

• Many people create groups to have a variety of titles. Associations wouldn't be useful for this unless they had as many roles as full groups (just without the land management role powers).
• Group notices are used in almost all active groups. So associations would probably need the power to send group notices. Just having "can invite to group" as group role permissions for associations probably isn't enough.
• Both full groups and associations would need to keep the role powers for "can start group IM session" and "can reply to existing group IM session", when these are put in place. If associations are designed primarily for chat purposes, they need whatever features are going to be put in place to help counteract spam.

What we really need is a developer Linden to look at this and see if this would help address some of the problems of server load caused by groups. If I could convert half my groups to associations, thus freeing up that number of slots for full groups, I'd be happy

As for the argument that it causes too much load, I cant see how. I guess it really depends on the behind the scenes architecture (which we all know needs an overhaul (again) anyway. Using the above example of having to check your access every pixel, I cant see why a single SQL query couldnt retrieve the appropriate data and comapre access levels - its not like you have to do (a broad example) if-else-if-else type coding to explicitly list and check each individual group that the user is a member of.

If its not done in an efficient way, it really needs to be changed so that it is - regardless of whether that change enables us to have more groups or not.

The problem here is that LL have a 4 year old platform which is rapidly aging, but they seem hesitant to change anything that is part of the underlying core for fear that it will suddenly stop working. That attitude needs to change.

I like the idea of separating groups into access and social... if I could convert some of my access-only groups so that they could not receive instant messages (read spam) I would do so in an eye-blink.

Why not make an option that paying memners will have more groups?

Using groups is not an idea way to manage rentals, because it means the process cannot be fully automated.

Perhaps, in this instance, finding a method whereby Land Options can also be assigned to named individuals would be the best solution, thus not only allowing the process of renting to be fully automated, but also allowing the tenant to be more precisely associated with a specific plot, and easing the pressure on groups to a certain extent.

Perhaps, also, purely social groups with no land implications could be given a new group lite status of some sort, to ease the burden on the servers, and allow a higher overall limit for groups generally.

1) Run SL in a window by clicking the "run in window" checkbox in Preferences/Graphics. This will allow you access to the functions of your PC, whilst not having to log out of SL.

2) Do a Google for "free automated rent programs". Download a bunch of those that suit you and test them out to see which you would prefer to use.

3) Use the automated rental program to send invoices to the people or companies that you need to.

For less prioritized group interaction (above the initial 25) use external e-mail.

1) Do a Google for "free automated email programs". Download a bunch of those that suit you and test them out to see which you would prefer to use.

2) Use the automated email program to send bulk notices/messages to the people or companies that you need to.

3) Smile as you watch SL turn from "crash test dummy volunteer course" to the world you wanted and helped create.

Network traffic is a poor excuse when people can conference call their friends list.

Now permissions having to be checked all the time, that makes some sense but surely this is done on a first check basis when placing objects? The logic isn't to check every single group, it checks your active group and if that doesn't match, you can't carry out the task, so the system doesn't need to scale through 100's of groups for each avatar.

Personally I'd like to see a system of different kinds of groups, security groups for land permissions, there's no need and often the owners of the group don't want, chat in these groups.

Then there can be social groups whereby people can chat.

Please read SVC-280 as it mentions why more than 25 groups would be a bad idea with the currently system. However, if we can get SVC-280 implemented first, then there's no reason a user couldn't have significantly more than 25 groups.

I am however all for such a feature being premium only, more premium value is a good thing.

I like the idea of "Associations" as a subset of "Groups", particularly for Groups that are principally used for Notices and IMs and Really Fun Titles but that don't really need to own land for anything. (Though the possibility to "upgrade" to a land-owning Group should remain an option for an "Association"--one such "clever title" Group that I'm in eventually came in handy for certain land permissions.)

I also support the notion of raising the Group limit for Premium membership, though obviously a mechanism needs to be put in place in the event that somebody downgrades their membership for whatever reason (perhaps dropping the most recently joined Groups above the limit.) The people who need extra Groups the most tend to be Premium members anyway, and if the Group limit persuades someone to pony up for a Premium membership, well, that money can go towards the necessary infrastructure to support the extra Groups.

A payment to have more groups seems a good option for bussines and developers to me.

Currently is use a alt to hold some shopownership and other misc groups.

My vote is in!

I've been capped for a long time and am constantly having to leave groups I want to keep, even resorting to "group-swapping" in some cases – an annoyance when the groups are free ... much more than that when it costs to join them. I have an in-world job that requires me to belong to no less than four groups, and I really need room for a couple more – just there. There are social groups, business groups, role-playing groups, product user groups ... some of us are active in Second Life, you know. I check the profiles of Lindens and see just a few groups for most of them. They need to get out and play and live and work in-world like the rest of us do and then they'll see how rapidly that 25 limit is reached.

I'd be ecstatic with a limit of 50, but 100 would be cause for real celebration. I'm all for groups with restricted functions, if that would help. It would also help to serve up group information to an agent on an as-needed basis, only. Until I asscess the information tab for a group, or until I attempt to use a group function I don't need that stuff. I have no idea whether or not that's even feasible under this system, though.

I cannot disagree more, though, about increasing groups only for people with premium accounts, and I'm a premie. Groups are one of the most important means of communication in Second Life and communication avenues should never be restricted

Also, I cannot stress enough that we can't just keep calling for more groups without first improving the infrastructure that provides and handles them as noted in SVC-280. 50 or 100 groups would double or quadruple the amount of data sent between simulators whenever a user crosses a region border or teleports, you think region crossings and teleports are bad enough just now, with more than 25 groups you'll see just how bad they can be =)

Not really. My understanding is that 25 more groups would add 900 bytes of data. Each group is just a UUID. The issue with sim crossing is script state save/restore and object state save/restore.

I am for this increase, it needs to be done, and unless the Agent tables in the databases are poorly designed it should be a trivial change.

I have to join groups constantly for my clients, so I can terraform or build on their land.

I have other groups that I have to be part of to manage my own property and that of my clients.

Every mall I rent space in has its own group that I must join, to be a merchant there.

The store that I sell my textures in has THREE groups that I have to be part of!

As a registered SL developer, belonging to the SLDEV group is mandatory...

I am ALWAYS having to drop one group in favor of another, so I can work somewhere else. I have to use a couple of my alts for the strictly 'voluntary' groups that I want to keep track of, like groups for other merchants to be notified of product updates or new product releases.

As it stands, if I get many more client groups that I must join, I'll have to do it as one of my alts...

For Merchants, I'd suggest the Lindens add a feature of Building Access, so that a Roster can determine who builds, rather than Group Membership. It would create a kind of Access Line, which would apply to building and Editing, possibly Scripting, rather than to Agent Presence. this might block a lot of Griefers, but I don't happen to know what they can do anyways. Building Access by Roster, as already by Group, is how it might be described. I don't think the coding would be impossible.

My understanding, is that Groups began as RPG Clans, of which Ten were allowed. Returning to that figure, but allowing extensions for the paying customers, would demand else than myself to help pay for the service. At only 25, despite my lack of Commerce and RPGs, I've been bouncing off my cap. When I get my massage Table on the market, I'm sure many would like them in their convenient malls, and I expect to be paid well, in many more than 25 malls. Merchants simply aren't looking for membership in RPG Clans.

Arawn

I'm for making the existing groups stable and making large groups work before adding more numbers.

Re: Angel Fluffy's notion of having groups devolve to "association" status if they have no $Linden activity.

This is overly intrusive and restrictive of freedom of association, nobody should be forced to spend money to keep a status, especially given how log-ons can break down and people can't get SL to work at all such as to come inworld and fix a problem like this.

I fail to see why the functions related to land, if they are empty and unused, are some kind of database draw or lag.

I'd rather not have some sort of second-class status for groups without land and with less permissions.

Between the groups I am in for land permissions and access, and the organization I help run in SL, I have no room for anything else. I'm always turning people down.

I seem to recall a similar proposal from the old feature voting system.

Most of the groups I belong to only ever need to be known to ANY simulator when I actually have that group active. They are not used for access, they're only used to grant build rights and set object ownership in one location.

How about increasing the number of groups to 100 or more, but limiting us to a smaller number of "live" groups for things like access control. In thr group window you'd have one more checkbox:

[x] Suspended.

A suspended group shows up in the group list in your own client (and possibly other places that are "cheap" to implement) but the sim (and any other part of the system for which group handling is expensive) doesn't know you're in it. When you make a suspended group your active group, then it's "unsuspended" as long as it's active, and then goes back into suspension when you take the label off.

Actually all the sim needs to do is cache the relevant permission info of every active group on than sim. Then it never has to request anything when new avatars show up. Though keeping the info fresh becomes an issue.

I have no idea how all this works now, but that is how it could work.

That way, the group calculations need only be done once.

I work in higher education, I teach and I manage our college island. There is simply no way I can do my job without having more than 25 groups. And another 5 groups are not going to cut it.

If Linden Lab wants people to continue their serious investment in both time and money, they need to give us the tools in order to be able to do out job.

Having read a few of the comments, another thing that strikes me is that the comments seem to cross all sectors, meaning this is not something that just one group or another wants, this is universal.

There could reasonably be a duration assigned to some group types. For example, its the norm for classes to be considered and treated as a group. The members of such a group are associated for a fixed and known duration. For academic purposes it's reasonable to have semester long groups (18 weeks would be a safe number I think for most of us). Thereafter a warning could be generated alerting the group member that their affiliation with that group will be ending unless there is someone with group management privs that proactively extends its length of life.

Whether this is a database problem or a design problem (they're using groups for too many unrelated purposes), the fact is that it would be a bug pushup to address the underlying problem.

That's why my proposal is to recognize the fact that MOST groups are not used for many different purposes, and are only used when they're actually your active group, and to allow you to mark these groups so that you're only treated as a member of these groups when they're active. Your group membership wouldn't even be stored in the same table with the other group membership information, it would be in a separate "suspended groups" table that would only be accessed when you're editing your group list, or when a group administrator is editing the membership list. You would effectively join and leave the group behind the scenes when it became active and inactive.

I cannot think of any technical reason for such a severe limitation on the number of groups except an outdated conceptual design that must be changed. I can think of a havy impact such a change might involve. Therefore, my suggestion is to solve the problem by redesign within a reasonable timeframe and at the same time to provide a few more groups (e.g. 5-10) based on the current concept on the short run. Cleaning groups or using alt's are definitely not viable solutions.

My personal suggestion to contribute to the problem is to implement an active/inactive member state. While still being a member of the group I have the option to set my membership state to inactive. This would be litterally the same as not being a member of the group. The difference will be that I will be able to re-activate my membership at any later time.

While providing a maximum of 25 active group memberships the list of groups a user can be subscribed to could be much higher without the big overhead. For me this would be a viable solution as it allows me to switch active member states whenever needed. I think for most others involved in land, shop and club management this would be good enough too.

Sure, such an option must be controllable by the group owner. Group managers must be able to grant or revoke the right to change membership states for their members. In my opinion this should take place at the level of roles.

To keep the lists as short as possible, I could even think of to automatically inactivate users from groups they have not used within a certain amount of time. The user could be promted whether he/she would like to continue to stay in the group, to be removed from group or to stay in the group as an inactive member.

In addition I would like to mention that any potential group functionality that doesn't exhaust resources could be provided as well. For eksample, while not being allowed to access or build on a specific parcel I could still have access to the group notices.

This is also nothing to do with the way any instant messaging scheme works. The problem with groups is not in the IM functionality, it's in the way all the groups you're in have to be considered for all the access control decisions made every time you cross from one parcel to another. This isn't something that AIM and IRC and the rest have to deal with, because they're just using the group as a directory.

First, I'm not Linden Labs or an employee of Linden Labs, I am a customer too. I don't NEED to make excuses for Linden Labs.

Second, I'm a programmer with over 30 years experience who wrote a primitive text-based "virtual world" application a quarter of a century ago, so I do have some experience in the general class of applications. Second Life is not just a chat system with graphics, and it uses groups for purposes that chat systems don't use chat groups for. Therefore arguing from the basis of the way chat systems work is specious. Which is what I was trying to explain.

The only way round this I've seen so far is to re-work the groups system to allow "has_permissions" flags (in which case you could still only be in 25 of those groups), and a further set of "no_permissions" groups which would require less checking server side and just allow you to receive group messages in those groups with no permissions to edit, build or enter parcels based on membership etc. (Which is basically as Argent says above). However, implementing that would involve a fairly complex re-write of both server and client code when there are probably more pressing concerns in SL at the moment.

In the meantime. If being limited to 25 groups is your most annoying feature in SL, I want an exact duplicate of the machine & software you're running SL on, and any relevant medication you may be taking

The scheme that Shy and myself are discussing should not require many changes to the infrastructure: it could be implemented by actually removing you and adding you back to the group... all the existing code would see the set of 25 or fewer groups it sees now, only specific components that needed to know about the "inactive" groups (your edit->groups window and the group "members and roles" tab if and only if the relevant box was checked, and possibly the IM subsystem if Onder's requirements were to be met.

Juggling, leaving, rejoining, just to get information I need in a timely manner is frustrating. Live musicians, venues, galleries, artists, openings ... all of these are important to me and what I do. I pay for a premium account I own a nice size piece of land I pay tier each month I buy and sell in SL regularly. I make up a percentage of the economy.

The 25 limit on group membership is not working for me at all.... I even have a notice in my Picks, apologizing to my groups that I may have to leave and rejoin just to do other work.
MORE GROUPS PLEASE!
(oh and the technical issue is not something I can comment on... but being as how we are in an age of technology breakthroughs ... I trust someone will make it happen soon ...Yeah they will "-)

There should be permissions groups, which could be limited to some arbitrarily small number like 25, to limit the network hit for enabling your 'Build' button.

And then there could be other groups such that they're for group IMs and such, pretty much like we have now. No limit on number of these groups, because they just send notices and IMs.

Most people doing business seem to have numerous groups like this anyway... A build/manager/admin type group, and an announcement group for customers. 25 is a reasonable limit number for permissions groups, and unlimited is a reasonable limit for chatty groups.

Maybe this should be a feature request.

That's not actually true, once a simulator loads your group it has all permission data that goes along with it, telling it what you can do. It then passes this on to other simulators as you region cross or teleport, so that they don't need to perform the same query again. I don't think it goes as far as to send group descriptions etc. around as well (they go to the client) but it's more data than just 32-bytes per group. That said; 900 bytes extra is still 900 bytes more than is needed and it adds up.

@Argent Stonecutter
"Most of the groups I belong to only ever need to be known to ANY simulator when I actually have that group active. They are not used for access, they're only used to grant build rights and set object ownership in one location."

But they could at any time be required for access, unless they have actually changed it then the simulator doesn't check, it just grabs all your group data (this was why LL were so reluctant to increase group limit sooner, and they never said it was addressed or not). This is what I am proposing be solved in SVC-280 (if it isn't already).

What does it matter if a group I've suspended becomes necessary for access? I'll get told about it, and I can make it my active group (and thus unsuspend it). When I activate it... it'll be just like I joined the group right then as far as the simulator's and presence server and everything else is concerned... and that stuff already works.

That is, suspended/inactive groups DO solve the problem, whether the underlying issues have been addressed or not, and your suspended groups could be unlimited.

Heck, I had to dump my own "fan group" because I didn't have enough slots. How bad is that, eh?

If not for lunatics like me so spend money on the grid, then at least for the lunatics who I spend my money on, okay?

Please, give us something we actually WANT!!

For the record: I don't want groups crippled, I don't want special Premium-only privileges, I just want more of the same. 440 people seem to think that MORE is the priority, as opposed to "modified".

I'm only bothering to make this point because there seems to be some banter here about compromises from the users in order to accomodate the issue. The users should not be expected to give something up. This 25 group limit is a flaw that needs repair. You can't just decide, because it's going to be tough to figure out a fix, that the users should pay the price for a broken system.

I mean, hey, if you're able to make a bunch of reduced-capability group types available to the public, by all means do so. I'm sure there will be many who will be interested.

But make that a completely separate issue to vote on. My vote was for more than 25 FULL-FEATURED groups for everybody.

That said... Those fashion groups are mostly for announcements and passing out flyers (as images) or gifts... They don't really need chat or roles or even titles... & unlike some I see no problem with making different types of groups... Fashion groups need almost nothing and so should be an insanely high number available you can have at once...

If not different types I'd support premium getting even 10 extra... I went premium awhile ago to donate my 512m of land tier to a group I was in...

But I'd love to have a nearly endless number of groups... That is ideal...

i do hope the data model is not as bad as some people have suggested. if thats the case it needs to be redone from the ground up for SL II.

votes don't mean something will be addressed. over 10 votes means it will show up in the more than 10 votes result set that means someone will look at it. and this is the public jira. the real assigned work happens in the internal jira. just because a jira entry exists here does not mean anyone at LL is aware of it.

the fact this is such an old issue, has so many votes, and has been ignored by LL indicates LL really pays attention don't they? enjoy your jira. its just another form of a forum.

personally i'm surprised this has not yet been closed as "won't fix" by a member of the fic.

If it really is an issue of exponential loads for introducing more groups then it's designed wrong, and should be a priority to rationalize as part of the het-grid project. Just imagine if people started using SL as a platform for real business and leveraging groups for proper access and security or product support. The mind boggles. Small group membership is a small grid phenomenon and if the grid is going to continue to grow it'll need better group tools and more groups.

I'd also be happy with the "group wallet" type idea - be a member of many groups but only have a certain number active at any time. This would allow one to switch on or off groups required for building purposes when needed. The data that represents the group woudln't need to be carried around on a permanent basis. One of the main reasons for having groups is to enable local activities, be they vendor placement, land management, entrance to closed sims or simply roleplay. When not engaged in that activity the group has limited utility and could easily be switched out - roles and other data could remain attatched to ones profile to be swapped back in when needed, but for that user the group would go into an idle state and not use up dynamic resources.

There's 3 things people are suggesting. Pump up the limit, remove the limit completely, or use alternate "List" groups that doesn't manage permissions. Personally I think any of the 3 solutions would be better than statu quo, which is really stifling business inworld.

I also believe this is not necessarily a feature request as much as it is a bug fix. I wrote about my reasoning here in my blog, http://blog.veyronsupercharge.com/2007/12/22/why-25-groups-is-a-bug-fix/

In a nutshell, if the database is too broken to support more than 25 groups and we all know the database is broken, than they need to fix the database.

A second advantage is that way YOU are in control of whether a group gets into the permissions bottleneck or not... not the group creator.

Such groups would have notices and proposal voting. But no land or object permissions factors.
These groups would not be visible in a deeding dialog.
these groups would not have any impact on the system that others have described above.
There is no bottlenecking concern.

This would allow people that demand membership in a group for communications to have a legit platform for their requirement.

The existing type of group with the suspension feature added would allow those groups to go on as they are but when you suspend the group for yourself you are suspending the group privs as though you are not a member at all. you would not receive any notices, nothing. you would not show in the group list. nada, zero.

Some people, including myself, would keep most groups in suspension all the time since group membership for us is tied to merchant rentals and we don't really want group affinity unless we are managing items in a store location. This is also a privacy feature. There are far too many people that assume you are making some sort of weird political statement by being in a group when in reality you just wanted to set stuff down in a rental booth.

I would like to see abilities within roles allowable and defined, such as Group Notices, Invites, etc, being limited to include only that particular Role within the group. This would make it much easier for managers and promotions staff employed under merchants to handle their respective duties without having to worry about mistakenly adding people to the wrong roles, group settings, and what have you.

at least for premium accounts more than 25 groups would be a VERY nice addition.

Sure, all of this only takes a minute or two, but I just don't have a minute or two in my life to spare for this kind of nonsense.

I'd be happy to support a two-tier system of groups, as has been discussed in this thread, with one kind of group existing only for group messages and chat.

Moreover, this could be a great source of revenue for LL. Premium account signups are down, and that's because there's no significant incentive for most people to sign up. It's time for LL to move to a model like the software industry uses: A free light version, and a paid version with more features and benefits.

Another feature and benefit: Help island staffed 24x7, available only to premium accounts. Basic, free accounts would stick with the current help model.

There are a couple of points in your message that I think do need to get cleared up, though, so thank you for giving me an opportunity to do that.

First...

The reason that I think it would be a good idea to let people join land groups without getting into the land access roles is because a lot of groups have land roles for a few people but most people don't use them for anything but the announcements. It would be convenient to be able to join these groups for the announcements without them being treated as permission groups.

If the distinction is in the level of membership in the groups, rather than in the kind of group, you reduce the number of groups it's necessary to create.

So while both approaches resolve the permissions bottleneck, making your group membership rather than the kind of group the distinction seems more flexible to me.

Second...

While the simplest implementation of suspended groups would remove you from the group for all purposes, I have noted that there is no reason that components of the system that aren't effected by the permissions bottleneck should not work for inactive groups. I don't think I've made that explicit in this thread, other than noting it as a possibility for IM type applications way back in the thread.

Going into more detail, the components that obviously need to look at that table are the group editor (and the corresponding mechanisms on the server that manage access to groups), and the members and roles tab (so that group administrators can administrate your ass). Those are the components I initially listed.

What other components would be available to suspended groups should obviously be a matter for discussion. I find Onder's arguments as a fairly compelling reason for including the IM subsystem if at all possible.

It would also be nice if event groups used web 2.0 online systems for group messages and calendars. That way it would decrease the number of groups I'd need to join in SL. Metaverse did this and I was really appreciative.

Flash-mobbing like this points up urgently the need for a NO VOTE FUNCTION. So that people can vote NO on issues that seem "wildly popular," so as to have some sense of reality.

There wouldn't be any need for any extra groups in SL, if people didn't make their groups invitation-only.

It's the widespread use of invitation-only that makes people fight for more groups, because once they get a scarce invitation, they don't want to risk having to badger the founder or officer to get invitations again.

Since I make all my groups open, I don't have this problem. I myself can leave a group to handle a temporary thing like a mall rental work for a few minutes to set prims. I'm beholden on that diva to send me an invitation however; but I don't make my own tenants do that as they can join and leave and join again any time.

Again, it's far more important to fix the existing bugs in groups, than to add more.

The issue has been explained in the past as a problem having to do with data base calls, and placing a burden on the system. Why can't the entitlement-happy accept that? If you need lots of groups, go on Facebook.

I honestly don't see that alts are somehow a non-solution. You can put the lesser important mall groups or news groups on the alt.

I'm also dead set against making actual inworld features break down into sets of options for higher-paying categories of customers. It would be hard to adjust this across one group, where there would be people with differing statuses within it.

Stuffing groups in alts is NOT a solution. Non invitation only groups is a red herring - really do you want to allow open entry on build groups? I think not. Prokofy may have a point from his perspective as a land agent, who others are beholden to for group access.

I agree with Prok that inworld features should not break down into a caste system where premiums get all the powers and basics flounder - that would also break or add another layer of restrictions to Prok's alt solution anyway. Renters, group builders and such are the folk who run up against group restrictions in order to carry out business in sl, and if they were premium land owners they likely wouldn't be in the rental consumers. Creating restrictions on basic is something I strongly oppose.

It's true the existing bugs in grops should be fixed, but the existing restriction on group numbers and their claimed load issues show that there is a problem with the way in which they have been implemented. Het-grid compliant systems which are future proof should scale elegantly rather than exponentially increasing load.

We need more groups - and Facebook may well show the way. The needs of many groups are simple communication, and a web2.0/IM approach to them would be fine.

Other groups are analagous to privilages in unix like operating systems - however alts do not behave like accounts, where inventory can be aliased between them. Though I can log in as an alt to place something, I may not be able to transfer the item from my main account to do so. One certainly doesn't want to throw away an officer role on a parcel to make room when you know that at some point you'll be the only person online able to respond to griefing or some other land management issue.

If the groups framework stays limited in number we NEED the ability to mark groups inactive and then rejoin them without chasing owners - it may be an inconvenience but the current situation is often a showstopper. (See http://jira.secondlife.com/browse/SVC-280 ) You can only wear one group/role at a time for doing work, so this would be a minor impediment. Similarly for social groups it is conceivable that folk could easily manage with a reduced number if they did not need to keep many groups active to ensure they are available at a later date.

Flash mob asside, this issue wouldn't have the support of the community if it wasn't a major annoyance.

I can't leave and rejoin ANY of the rental groups.

And they can't be left open, because access to the group is how the malls keep squatters out.

Chat can be handled other ways, perhaps, but the number of access groups MUST be fixed one way or other, and the "suspension" model would handle that.

www.lunajubilee.blogspot.com

Raise the limit to 100, at a minimum.

And, you know, anything Prok hates, must be good. Prokofy Is Always Wrong.

ALL vendors should make said announcements via a script that broadcasts the messages to paying customers. If they don't know how, then they should learn.

and I'm against charging much more than the price of an asset upload (usually this is an ammount an newbie can get relativelly easy) for joining each extra group, and it wouldn't please me at all if it was anything other than an one time fee

but like people said, fixing the system would allow for more groups with no extra cost for LL and would most likelly help speedup lots of other work that would bump on such bottlenecks

as for people displeased with the benefits that come with premium accounts, create your own JIRA entries or in some other way try to get what you want to say be heard by the peeps that can do somthing about it, hijacking other JIRA entries is not polite

ps:since I've said lots in here I feel it would be better to add the warning that I might have got my words or concepts jumbled up at some points (don't think I did, but the risk is present)

This would have to be the most single useful thing to add (apart from fixing all the tp probs, stuff up the ass, inv loss etc etc) and laggy or not, would be certainly more worthwhile and worth the lag hit compared to the unloved, unused and unwanted Voice, and probably Windlight unless you happen to have a $5K personal Cray and your own chunk of backbone.

Now, we don't need to go mad here. 50 limit would be bril, an extra 15 very happy, even an extra 10 would be super duper...

Again, if people outside the US could become premiums more easily, if there were more payment methods, and all our IDs didn't fail Age Verification, then yes, consider charging for it, but personally I'd rather scrap some of those shinies to make room for it.

And that's a bad thing, unlike a blog entry titled "STORM THE JIRA!" from back in mid-November, right? Surely if someone feels strongly about an issue, he or she has the right to urge people to look into it and vote for it if they are so inclined.

Or maybe the difference is that this issue currently has 658 votes, whereas WEB-382 has, at the time of this writing, four.

I think that everyone who's spent much time in SL has beaten his or her head against the twenty-five group limit, and seriously doubt that the "coterie" has done much to "fan up the votes" other than pointing to the JIRA entry and letting people know that someone has had the same problem they've had and taken the first step to getting it fixed, and they can help.

• Allowing to manage/control ownership and permissions on land;

• Having means to broadcast messages to an indefinite number of people with similar interests;

• A nifty way to wear tags over the head thus demonstrating a particular sense of belonging to a certain community;

• etc.

Would it be too too far off to think about introducing new concepts to accomplish these different purposes?

E.g. having some sort of broadcasting channels without the overhead of maintaining group roles, ownerships, permissions etc. solely for the purpose of allowing communication between community members?

And having some tagging feature allowing to create some title to be worn?

A lot of groups are used for purposes which simply don't require all the overhead currently imposed on groups. If new "light-weight groups" for those other purposes were introduced it would lift the burden off the whole group system and groups can be more accurately used for their originally intended purpose which is to be seen in controlling land-related permissions and options. Perhaps this would allow the Lindens to increase the group limit which currently is a real restriction for landlords, mall managers and other kind of business people.

As one of the early voters on this issue, I did not "flash mob" it, I voted for it because my Second Life is greatly impeded by the current limitation on groups.

I am, among other things, a second life mentor and need to be in several groups for that (mentor buddy, mentor linguist, etc., etc.). I need to monitor several groups to get notices for updates on various avatars, utilities, HUDs, and other essential items. I need to keep up with the IM chat and conversations in groups like Second Life Builders and Second Life Scripters, etc. I need to be in other groups simply to be able to walk or fly on land owned by friends in sims with group membership restrictions. On and on it goes, the simple fact of the matter is that I need more groups just to be able to function normally with an active and healthy Second Life.

Now, rather than answering with the first pet "fix" I may think of, I would guide our essentially wonderful Linden Labs software development team to use simple modern software architecture and design methodologies to identify and model the domain and the problem. Try starting out with a nice little UML Use Case Diagram that identifies the various kinds of group users (actors) and names and depicts the various ways those actors want to interact with the system (Use Cases). Anyone involved in serious software engineering design should know how to do that. It is always one of the very first steps professionals use to deal with a problem such as group limits. Model the Use Cases; generate the requirements.

Perhaps by identifying all of the use cases, LL staff can determine how to properly think about identifying and solving the various disparate requirements that have been bundled into the current broken group system.

I caution that there probably is not a single workable solution to a single problem that has a single cause, here. More likely, we have multiple problems, each created by multiple causes that have been rolled up into one statement (we need more groups). Thinking about those multiple problems and multiple causes may help LL to generate multiple solutions that together will make Second Life better for all of us.

Synth

My suggestion is to add the ban/allow list. See MISC-870 as to partially resolve the concern brought up on this thread.

The ability to suspend group membership ... leave the group for all permission-related (land-group) purposes ... would solve the problem and also allow people to retroactively treat existing groups as IM-only groups.

Even with thousands of people coming and going, griefing and squatting is actually quite minimal.

Mall owners shouldn't own more land than they can personally keep an eye on or hire people to spot check to prevent things like squatting or things not allowed on the lease.

It's the habit and culture of wanting to make SL like an armed camp and a maximum security compound that has spawned this need for all these groups, with all their layers of permission – this group for the inner circle to talk and keep out the hoi polloi, that group to make the hoi polloi set their prims, etc.

If you spent only 10 minutes a day on each of your groups, chatting, managing land, etc. that would already be FOUR HOURS of your time each day in SL.

Simplify, simplify.

@ Lindens - Since this thread has turned into more then just asking for the ability to join more then 25 Group please add me to the wish list. I propose two group levels. Basic: Free & Open with a selection of today's functionality such as notices for "malls" and the likes..limited to 25, and a Premium: type which has privacy controls, more aligned for Estate Management... Unlimited with a Fee?

I honestly do not see it happening with all the coding effort...not to mention the whining.... there would be in converting the current groups.

Thanks!

I guess by your comments you think that it's a good thing that people should have to waste time during their real day to keep people out of their virtual property. I'm also pretty confused by your last comment: why should I spend 10 minutes a day in each land group that I have a vendor in? I spend less than 10 minutes a month in most of them.

TheDiva: the mass of existing groups is why I'm proposing making a change in the way membership works, rather than making a change in thr group itself. If you're not in a group from the point of view of permissions then your membership in that group doesn't need to be kept track of by the sims and the permissions system, but if you can temporarily activate it when you need to then you can still suspend your membership in many land groups you're currently in, without having to return to them every time you need to update a vendor.

But to the actual topic. "Just make all groups open" is NOT a solution. It's just a recipe for another problem. If I want to get notifications from more than 25 groups at once, leaving and reentering them won't do the job. And even if by some miracle griefers aren't taking advantage of the open security to plunk grief-objects (or vendors for that matter) in every mall, it's only a matter of time until they do, and then we're in the same pickle all over again. Might as well deal with the issue now. Policing your land 24/7 is also not an option. We have these machines we call computers, you see, that can help keep people from having to do tedious tasks like that. Might as well use them. There are days/weeks when I don't log on to SL. I could go on about the inapplicability of this "solution", but it would just get boring.

"Suspended" groups sound promising. But maybe I'm missing something in general (I don't have the amount of SL experience that many of you have): in what sense are groups that I am in, whose nametag I am not currently wearing, "active" in the first place? I get notifications and IM from them, but those features are proposed to remain for "suspended" groups. I can't build as them, without "activating" them. I get charged for group-owned land and other financial doings, but those don't sound like things for which I need to carry my group membership from sim to sim: they aren't dependent on location. I guess I can set group-ownership to an existing object, though. Is that the only reason for this purported network load that carrying lots of groups around is said to cause? And is it really so commonly done, to set group-ownership of an object into a group you don't feel like activating? Otherwise, it sounds like just about all groups can be suspended except the one you're actually using.

I'm actually a little mystified that a few dozen or hundred 36-character UUIDs (not even encoded in full 8-bit binary) can be considered an excessive network load in a system as network-intensive as SL, that sends around all kinds of positional data, textures, etc etc. But I never studied the network architecture of SL, so I accept that this is true.

I generally oppose solutions that only help Premium members; there are all kinds of reasons preventing people from getting premium accounts, and they may need the extra groups as much as the rest of us.

As to the difference between "suspended" and "not active":

Even if a group tag is not active, you can create objects on group owned land if the group abilities are set to always allow group members to create, and other group role related powers (fly, terraform, create landmark, etcetera) apply even when the group tag is inactive, you can enter group-owned land without the group tag active, you can change the group ownership of objects and deed objects to groups if you have that ability...

I like Argent's "suspended group" idea - that would solve a lot of my personal problems, as I am rarely building in more than one place at once, and I can't see any downside to it - though I don't know how whether there are any practical reasons why it might not work.

In addition, simple groups which are only used for notifications and/or IM, and provide no other privileges, should certainly be almost unlimited. This would solve a lot of problems, as most residents might belong to a few groups for, say, renting or camping or whatever, but in the main, they are for keeping track of new releases, new event announcements, or chat. The current group system is a huge pneumatic hammer that is used to crack everything from walnuts to concrete blocks, and we have more walnuts than concrete blocks, I believe.

Incidentally, I say this as someone who has built up a multi-billion pound software empire single-handedly, just one I'm too shy to name, and also as the reincarnation of Babbage, Lovelace and Turing all at once.

(I just hope for your sake you're not Bill Gates Xp

http://nwn.blogs.com/nwn/2008/01/robin-linden-on.html

So, as I read through the nebulous double talk, they don't really understand how this aspect of the existing system code operates and therefore there is little hope for such a simple requirement to be implemented without actually tearing the code apart and having it rewritten by competent system architects. Apparently the people who designed this part of the system have left LL.

Had secondlife been engineered from the ground up to support true object oriented design this would not be a limitation. However it was put together on the fly as they went surfing the bleeding edge of technology. Not really a surprise or a bad thing. Secondlife was built pile upon pile of code. LL has the money to do this right and owes it to the planet to take the step forward to bring on the correct highly compensated talent to take the requirements and put forth a true system architecture to meet existing and future needs.

And one day pigs will fly. I say this because Phillip Rosedale has already flatly ruled out the notion of proper software engineering in discussions with the press during which he stated rather boldly LL favors an on the fly code pile upon code pile strategy instead of a total rewrite. We can hope that one day someone else will do it right and LL will be remembered for starting something they were not capable of finishing.

It's been a nice debate although in the end it has been an utter waste of time and energy.

In the meantime any mall owner that requires a merchant remain in a group should be ignored and allowed to go out of business. Groups are now nothing more than a transient permissions setting device. Nothing more. Groups intended for use as a communications medium need to be migrated out of Secondlife where the requirements can be met with properly engineered code. One example of a start at doing this is subscribe-o-matic. Fashion Consolidated needs to be moved to this type of platform as the weight of so many group members breaks it anyway. I dare say not only is there a limit of 25 groups but it appears there is also a true limit of about 25 accounts per group before the group becomes at risk of failing.

I.e.;, we will have to fix this without Linden Research because they don't have what it takes to do it right.

Suspended groups would not contribute to the database load while they were suspended, because they would not be in ANY of the tables that are acting as a bottleneck.

"we will have to fix this without Linden Research because they don't have what it takes to do it right."

We could, if there was a couple of LSL calls: "llGroupInvite(key agent, string role-name);" and "llGroupEject(key agent);".

The latter turns out to be a duplicate of MISC-388, so I closed my own proposal as duplicate.

Well... you can say "more than 100 groups !!!" or even "more than 1 000 000 groups or no limit !!!" but I voted for it !!! I guess it would be better to have possibility to join to more than the 25 groups.

I open other improvement issues:

VWR-3825 (better group management),
VWR-3824 (better contacts management),
VWR-3826 (better parcel/land management).

Vote for them.

Best Regards,
shaq

When they don't like a proposal, or it doesn't appear "popular" as this one has become, fanned up by Hamlet Au, they instantly cite even far-away, long-ago Linden vague pronouncements about "can't do" or "won't finish" because "too hard" or "too costly". Then Linden writ is law.

But here, we have a robust, definitive, unambiguous statement from Robin Linden, VP of Marketing and Community, which crystalizes what other Lindens have said for weeks (like Periapse) and is summed up as CANNOT DO BECAUSE TOO HARD:

http://nwn.blogs.com/nwn/2008/01/robin-linden-on.html

namely, that it's too expensive a load on the data base.

And yet all these fanboyz who always berate us in other proposals about "feature creep" and "users who ask for pie-in-the-sky things without any awareness of the load" etc. etc. – they are silent. They are voting for this.

I'm not. Because while the Lindens have their own agendas and are selective about telling the entire story, on this one, they make good sense. It is an expensive call, to have to have servers checking constantly for groups and roles and permissions.

Therefore I don't vote yes for this one and I wonder why all this busy little closers that go around closing everything else because it's "too idealistic and impractical" and "the Lindens say they don't want it and won't finish it" aren't bustling around now, eh?

I feel utterly dirty saying it as always but as much as I'd love to have more than 25 groups, and I did vote for this incidentally, I don't see this happening for exactly the reasons given and that is server load which is a linden acknowledged problem when it comes to more groups. I'm going to go ahead and close as won't finish.

There are several proposals out there to change the way groups work to allow the group limit to be increased.

Therefore it is premature to close this proposal.

lol, has that always beent here? Xp

It was the general opinion when LL expanded groups to 25 that it would be far too small an expansion. Most people commented that at lest 100 groups would be needed. Even if they expand to 50, it will still be too few groups.

For those that argue such would increase network traffic... in what way does group membership increase network traffic? Group membership is a database issue. A computer can search through 100 groups just as easily as it can search through 25 groups. It's faster than the blink of an eye, no matter which... IF the server database is set up correctly.

Merchants need groups to set up shops. Groups need subgroups to handle specific needs. People belong to groups of special interest.

25 is way too few. 50 would be better but STILL too few.

IMO, LL should get away from STATIC DATABASE concepts and start using DYNAMIC DATABASES. I mean get real. What is this, the dinosaur age of computing where we only have 4k RAM to work with? Get with the times.

We need AT LEAST 100 groups to function properly, and preferrably more. Adding 50 will be just like adding 25... before long, people will be needing more than 50. If LL really wants to be smart, they'll reassign groups to a dynamic database structure and let people have as many or as few groups as they want.

Gwyneth, the comments posted are not the way computer databases work.

You mentioned (if I understand correctly) that every time you move a pixel, the system has to check your group databases to see if you're allowed ina parcel, etc. Not so.

With most graphics systems, the system refreshes a certain number of times per second. It is programmed to either check these things every refresh cycle, or ever certain number of refresh cycles, or IF you are crossing from one parcel into another. For example, if you are on a large parcel, it does not have to re-check those things while you are still in the parcel. It only needs to check to see IF you have entered another parcel, and if you have, THEN it checks group issues.

Now, there are two primary ways to handle a database: sequential and random. If the file is sequential, yes, searching 500,000 group files would take longer than searching 25. But searching 100? Pffft. The difference in nanotime technology wouldn't even be noticeable. The computer could burn through 100 records virtually as quickly as 25.

If the file is RANDOM, it's even faster. Because whether you have a database of 25 or 25 billion, any file within that database can be located in 13 search steps. No matter how large or small the file. Now yes, in a database of 25, it might happen to hit the needed record on the 2nd, 4th, or 7th search (or anywhere in there) and save a picosecond of time perhaps, but in ANY size database, by the 13th search it has the record. That all happens in a split second. Zap zap. Got it.

That is with reliably programmed databases. The problem is that as everyone is aware, LL asset servers and databases appear to be borked. They don't seem to work correctly. Now I don't work at LL, have never seen LL, don't know how their particular system is set up. But I do know this: aside from simply basic storage space, it should be just as easy for them to provide us with 25,000 groups as it is 25. It's shouldn't cause any strain at all on the search engines, no strain at all on the network system, no strain on anything. A database is a database. It is the BASE of DATA on any computer system and managing databases is really the bottom-line aspect of computer operation. There should be no difficulty in accessing and tracking inventory, no difficulty in group chat or group notecards, no difficulty in joining 500 groups if that's what the user wants. But bottom line, LL does make arbitrary, knee-jerk, "easy" decisions, sometimes without consideration for the needs of their customers. Hopefully all that will change soon, because competition is coming. The time for half-baked recipes is over. Like any other company, they will either meet their customer's needs, or they will fail.

From Jonathan Linden on SLDev:
The current behavior is as follows:

When you double click a group IM session to "start" it one of two things happens.
1) The group chat session doesn't exist, so a "new" session is started in which all online group members are looked up and added to the session. This group member lookup is the cause of much DB load and there is currently no way of opting out of this. You get the IM regardless if you want it or not.
or
2) A group session exists and you are just added to it. No members are looked up, you can potentially join a session with 1 other member in it.

The user currently has no way of knowing what scenario will happen and this is very inconsistent. The user has no way of opting-out of group IM. Even if you get a group IM and close it it is possible that you will receive another group IM later (if there was a session that just ended and the code goes down path #1 again, you get the IM regardless).
Also, when you log in, you are added to any existing group chat "passively" in the sense that you do not have to open your tab to receive an IM (or a little group voice chat pop up). Doing this adds minimal load to the system but is also opt-out. You'll receive any IMs to the group after you log in regardless whether you want to or not
(unless you open and close the tab, but even then you may still get a group IM if a "new" session starts up and all online members are looked up.....sigh).

Now granted, that may be the way LL has it set up. No way of knowing. But it's sure not the way it SHOULD be set up.

You gave an example of someone changing a parcel layout. How often does that happen really? It happens all the time, but in ratio to online time as a whole? Miniscule. And if the system works properly, it will only check group affiliation of people IN that parcel WHEN and IF the parcel is changed. In other words, you don't constantly check each person's group to see if it's still allowed on the parcel. You only make that check IF parcel parameters have been changed.

And yes, having 200 groups might cause slightly longer login time. A second maybe. Two seconds? Hard to tell. But considering that a computer can load a several-megabyte program in about four seconds flat, the time again, is comparatively miniscule. That is why people gripe so much about failed logins and teleports. Do you know how EASY it should be to login or teleport? Compared to other game functions, it should be one of the easiest things in the game. All it should entail is simple transfer of data to the new server and hooking your avatar database into server parameters. That SHOULD be straight, point-blank, almost-never-fails straight forward programming. As simple as sending an email in fact. The fact that it fails so often is a sign both that the asset servers and database engines are not working properly.

But again, as far as checking database parameters: from a computer's standpoint, the difference between checking 25 groups and 200 groups is infintisimally small.

As for the group chat causing load that results in group chat errors, that is a bug that has existed off and on for a long time, reappearing some times when a release is insufficiently tested. It really has nothing to do with the number of members in a group or how many groups each avatar belongs to, i've seen group chat errors in groups of less than 25 members.

And Kami, you are right: Anything Prok hates is inherently good.

This does not mean that Prokofy is right. He does not seem to be a particularly technical fellow. It does however mean that when Robin says database operations on groups are a bottleneck then simply increasing the number of groups is not likely possible. That doesn't mean there are not going to be changes in the group system, or chat, or permissions, to resolve the problem one way or another. It simply means that the question "why wouldn't LL increase the limit" has been amply answered.

intlibber: groups were increased to 15, not 25. The increase to 25 happened later.

And the linden argument is rubbish too. What it basically means: "we messed up the initial design, wrote awful SQLs, and now we would have to spend a considerable time to implement a sensible solution."
Or second meaning: "we don't wanna, and we just give you some technical sounding gibberish for an excuse, maybe you will suck it up, and leave us alone."

I can accept even the latter answer, but say it straight : "die punk, no can do".

• Get rid of group membership being a requirement for changing the 'group label' field, so that people don't need to create groups to set a label.

• Allow parcels to explicitly maintain a list of agents that have rights independently of group membership, so that a mall owner can have a script grant build rights and disable autoreturn for a vendor's objects without having to have that vendor join a group.

• Allow groups to be "permission-only" so they do not have to be visible to chat.

• Allow groups to be "chat-only" so they do not have to be used by the permission system.

• Make permissions or chat into group abilities, so that a group could limit them to specific roles, and the permission system would not need to track people who did not have any permission abilities, and the chat system would not need to track people who did not have any chat abilities. (this is a variant of the previous two suggestions)

• Allow people to opt out of group chat, so they don't show up in chat.

• Allow people to opt out of group permissions, so their membership in groups doesn't have to be visible to the permissions system.

• Allow scripted control of group membership (MISC-388) so that people could be invited to permission groups temporarily without requiring human action.

• Allow people to temporarily leave groups without having to pay or request to rejoin (the original version of SVC-1173).

• Implement a non-group chat system.

Some combination of these changes will be needed. Your mission now is to argue about which of them will be least disruptive.

In my use of groups, thus far I have only seen two applications of high use for me: 1. Granting permissions to do builds on my land. 2. Mailing List / Notices.

My use of Second Life is educational, non-profit, community building, computer based conferencing, personal growth, etc. I want tools that support these activities. 99% of the permissions / memberships / roles in the current group structure do no appear applicable to my work. The few features of groups that I do use, are important.

I will review groups further and the comments made here. I too have been confronted with having more groups that I want to join than I can join. In some cases, I am in a group simply so I can run my information booth – granted, there are many vanity groups in Second Life, which exist simply as a form of demographic association or a way to have cute qualifiers floating over one's name.

All the best
Skye Ranger Pinion

there are more odd little things going on here than meets the eye. LL is aware of the situation. I hope they can concoct a safe solution pretty soon.

1) The reality is that groups are being used to manage access rights (build rights) to land. If this were able to be accomplished another way, for example through land properties, it might reduce the number of groups necessary. I'm not saying that this is the correct way to architect this solution, but I am trying to point out the observation that there may be other avenues of accomplishing the same end goal.

2) There have been a lot of comments about the impact that increasing the groups would have on the environment, however I am not certain which comments are based on intimate knowledge of the Grid/Viewer code, and which are comments anticipating areas that could have potential issues. It would be helpful if someone intimate with the implementation could comment on the real issues behind expanding numbers of groups (perhaps a Linden?).

3) From my personal experience in SL, even if land rights were managed outside of group membership, 25 groups does seem low. Currently groups are being leveraged for at least the following purposes: Vendor mailing lists/offers, Venue event notifications, Performer/artist/expert event notifications, Object access, land access. Maybe a casual user won't have many of these, but someone quite involved in SL will likely have many. (5 each of the above categories, and you've reached your maximum). Switching groups between alts is not a valid solution.

4) I'm not opposed to the concept of giving more groups to premium members, however I think the minimum groups given to basic members still needs to increase. With an increase of groups, better group management (group classification?) would be desired, but not necessary in the short term. Other features (options for specific groups – such as the items suggested by Argent above ) that may cut down on the overhead impact of more groups should be considered in the short term if they can reduce the resources necessary and therefore provide a better means for SL to support more groups per resident.

Feel free to contact me by IM/notecard in-world if you have any questions about any of my comments.

A. Land related and other permissions related groups

Land management/ownership groups 12
Rental/land access groups (a) 13
Object and other permission sharing groups (b) 4

Total land/permissions related 29

B. Professional/business/education related groups

Staff/employment related groups 5
Teaching/training related groups 5
Business/finance related groups 2

Total professional/business related 12

C. Social networking groups

Event notification groups (c) 37
Update/resource notification groups (d) 26
"Pure tagging" groups (e) 14
Topic/hobby oriented social groups (f) 7
Social interaction/chat groups 6
RP/GWIG related groups (g) 2

Total social networking 92

Total all types 133 (h)

Notes

(a) I am making a distinction here based on group membership involving permissions and privileges at the ownership level (i.e. being one of the owners of the group or having land management abilities comparable to the owner) versus groups that involve land management but in which I am not one of the members with land management privileges. Examples of the latter would include groups one needs to join in order to place a vendor at a mall, and groups that use land where access is restricted to group members only. I hope it is clear that these group classifications may differ for different group members (viz. depending on whether they are a group owner/manager)
(b) These are essentially groups that exist for the purpose of managing in-world objects that are deeded to the group for ease of management. This includes at least one "fossil" group that historically served a different purpose but is currently only kept in existence to preserve certain non-transferable objects deeded to the group that would be lost if the group were dissolved.
(c) Under this classification I include all groups that exist mainly for the purpose of notifiying members of upcoming events, mostly so-called VIP groups associated with a particular club or other entertainment venue. Note that although their purpose is essentially social, membership of some of these can be employment related: staff needs to be a member of the VIP group in order to send out notices, invite new members, etc.
(d) Here I have placed all groups that notifiy their members of things that are not primarily event related, which includes everything from product update groups like Fashcon to resource hunting groups such as lucky chair and money tree hunters.
(e) This includes all groups whose main or only purpose is to give their member the ability to wear a nice tag over their name. Some of these may develop into more socially interactive groups over time.
(f) These are groups dedicated to social interaction focused on a particular topic of interest or hobby, such as linguistics or building.
(g) These are groups dedicated to social interaction in the context of roleplaying, including groups dedicated to OOC communication and discussion groups for games-within-the-game (GWIG) such as Tiny Empires
(h) I trust nobody will be surprised at this point that I have 6 alts

One striking observation that very clearly emerges from these data is that 92 out of 133 groups (69%) are NOT groups expected to involve any deeded object or land permissions requirements that apparently cause groups to put such a disproportionate load on the system (as indicated in note a, those social groups involving land access issues are not included in this total). In contrast, only 42 groups (31%) inevitably require such resources. This strongly suggests that if simulator load is a major concern, one rather obvious solution would be to allow two types of groups. One type would provide the full range of management and permissions abilities currently afforded to all groups (and which apparently cause such a strain on the system). The other, "light" type of group would provide the communication abilities (group IMs and notices) but would not involve any permissions or abilities that need to be constantly monitored on a sim-by-sim basis (Proposals under MISC-767 and MISC-847 call for something similar ot these "light" groups, so it might be useful to refer to them).

I personally have no problem with requiring some kind of extra compensation for setting up and using "fully loaded" groups. However, as premium membership is still demonstrably somewhat discriminatory against non-US residents, I would prefer the requirement to be group related rather than payment type related: for example, raise the creation fee for a fully loaded group to 500L$ while keeping the required fee for a light group at 100, and possibly requiring fully loaded groups to charge a minimum signup fee of 10L$ or so. This would allow all residents to join both types of groups equally, yet acknowledge the heavier system requirements of the fully loaded groups. Existing groups could be grandfathered in by allowing the owners to make a one-time decision to keep their existing groups fully loaded or switch them to light (or possibly switch all groups that do not own land or objects to light by default but allow the owner to upgrade them to fully loaded if desired).

Under these conditions, I suggest that fully loaded groups be subject to a reasonable upper limit. Based on my own data, 40 seems reasonable, but if groups for social purposes are taken out of this part of the equation, even retaining the present 25 group limit might work. I suggest that light groups be either not limited or given a generous upper limit of 200 or so.

Comments and suggestions welcomed.

The problem is that while it is these operations that create load on the system, all groups have to be tracked for permissions, and access to the group membership table is what causes the load... whether or not the groups in the table are "loaded" or not.

Splitting groups up into two types by removing "light" groups from the group membership table that the permissions system accesses will reduce the load, but it will do so faster if existing group memberships can be removed as well. Which was the purpose behind the "suspended groups" concept that a few people (myself included) came up with. This would allow you to make the distinction as to whether groups you were already in were "light" or not, by yourself, without having to wait for new special-purpose groups to be created.

What is this JIRA for? Robin addressed none of the solutions proposed in this thread. She could easily have done so. That she did not indicates that she did not read our input before indulging herself with Delphic utterances, or that she had read it and chose to ignore it. We are told JIRA is a two-way street where the Lindens engage in dialogue with users. I would really like to believe that. I really would. 8 months and 22 days argues quite strongly that I should not believe it. Nor should anyone else.

As far as solutions go, at some stage there will be land groups and contact groups. Land groups will look very much like our current groups and will probably be limited in number. I agree it would be appropriate to charge more for a land group than a contact group. The idea of suspending groups is great as a transitional measure, but would no longer be needed one the Lindens recognise groups are performing two sets of functions so we need two sets of groups with different functions.

The other set of numbers it would be really good to know is how many users are loading the system down with alts that exist only as a way of accessing more groups. I suspect if that were investigated the Lindens would find the 25 limit is loading down their systems just as much, if not more, as restructuring the groups with new tools would do.

I agree that a redesign is needed. All groups shouldn't be equal, there is often no need for an update or information group to play any role with land permissions.

Personally I get most of the social group info I need from gcal and outworld services, not because I wish to, but because I need to. All of these social groups are such that I only ever need IM, parcel access and the occasional announcement. There's only room for a couple of those kind of groups in my list.

I think you'll find that anyone who's done a bit of freelance work, mall vending, or group building in SL is in the same boat - there's not enough groups to facilitate a reasonable number of social groups in the list once they've been filled by work. Out world tools may be ok for announcements and such, but they're no good for community.

If creating different types of group would lower the strain on the network, I think it would be a good idea. But I think it is probably simpler to leave the structure of groups as is, while increasing the number.

The workaround of having alts does add to the fun of the grid by increasing the (apparent) population and does generate a lot more revenue for Linden Lab (and even for inworld businesses, since they can sell multiple copies of an item to a single typist.) But extra avis must also cause a whole lot more load on the grid than a larger group limit could cause. (There are other reasons aside from group slots to create alts... and in fact my alts belong to several groups in common, including our own family group.)

The messaging can be worked around by doing Friends conferences and/or by using a script which goes through of a list of recipeints... but this is cumbersome (and unlike with Groups, there is no easy way to opt out short of muting the sender and/or harassing him/her/it.)

We know this issue is hard to resolve, but not impossible to resolve, so please LL, give us something we actually want and are demanding!!

Every business has to listen to it's customers in order to survive and as we, the users are the customers of LL then we should be the ones to call the tune and ask for what we need.

I agree that the increased group limit should be available to premium users only, as after all, we're the ones who generate the revenue for LL, plus it should very much be an appetiser, an incentive or perk in order to generate other premium accounts, therefore making LL more successful.

Stop giving us excuses and start giving us results please. We, the people, have spoken and we demand more groups!

I'm getting fedup of juggling around with groups as by the looks are the 1108 folks who have voted on this issue aleady. Anyone in LL listening to us. I agree that having a limit means you need to think about the groups you are in but 25 is just not enough given how much SL has expanded.

For example, groups could have two settings: enabled or disabled, set by each avatar independently. One can be a member of up to 25 enabled groups, which function as normal groups. Disabled groups would be trimmed to the bare minimum: notices, group chat, listed on profile, and other services would be disabled. The services that would be active would be the financial functions: donated tier, dividends, and liabilities. This would allow individuals to swap out the groups they need, without leaving them. It would also have the added benefit of muting high-activity groups that one wants to be a member of, but doesn't want to be inundated with notices, group chat etc.

I'd suggest the following possible group types. Maybe even call them by different names. Since some have only a subset of current Group functionality, they would a) potentially impose less load, and b) actually make some groups more usable (especially one way announcements).

• Land or region access lists - for example the landlord's resident and guest list.
• One way announcements - for example Advanced Scripting Class to XYZ University Members.
• Shared interests - for example Pirate Events, ARRRGH, mateys.
• Product owner support - for example "Here's how to get your XYZ vendor to do whatever".

I make avatars and rent vendor space. Vendor groups.
I am a DJ. Club groups.
I love to roleplay. Roleplay groups.
I lack room for interest groups, which is driving me insane.

Now I know that some businesses have update groups which people join because they love to be able to keep up with the products and updates for things that they already have, thus people have one of these per store that they frequent and shop from in order to keep tabs on the place. As Vasha said, they are a multiple SIM owner and I'm sure if they run things on both they have a group for each of those activities in order to send out notices to their visitors or if they are role play SIMs in order to send out needed information to their players on SIM wide RP. I suppose in closing, I have to say that adding ten to fifteen new group slots would be a needed and seemingly very wanted addition to the grid structure and coding. Looking at the 1200+ votes I would say that my deduction is quite accurate.

a) more roles, at least 64 roles max. This would allow for large complex organizations to operate within one group more effectively. Merczateers for instance, has many ranks and divisions
b) allow for subgroups within the group: for dealing with divisions within a group: like military groups have infantry, aeronauts, fleet, medical, R&D, etc. so to with businesses, other RP groups, etc.
c) allow for assigning of abilities based on role and/or subgroup
d) allow for limiting who can chat as an ability, and an ability to ban certain individual members from chat and to ban individuals from joining open join groups.
e) allow all land owned by the group to share a common ban list or to check banlists on other parcels owned by the group for bans when an individual enters the parcel.
f) assign parcel access based on subgroup
g) enable lsl functions that make group owned vending and other money devices work as well as those owned by individuals (i.e. deposit/withdraw, move funds between accounts in the group, etc)
h) make the ability to manipulate group owned money objects separate from the regular ability to manipulate group objects.
i) enable the group founder to demote a coowner themselves
j) enable the group founder to designate an heir to inherit ultimate control of the group to ensure continuity of leadership
k) separate payment of liabilities from the receiving of dividends abilities
l) allow group founder or other role to decide when to pay dividends and how much
m) enable a group to accrue savings in the group
n) enable the group accounting to maintain multiple accounts to save funds in and transfer funds between
o) while normal members should be able to hide their membership in a group, owners and officers should never be able to do so. those with executive responsibility for group actions should be publicly accountable for the groups actions.
p) allow for more than one role to have 'officer' rank in the group
q) allow for one account within the group to pay interest to another account within the group
r) enable roles to see accounting information about the group without having ability to expend group money

i say yes to the idea. I role play in millitary sim's and i'm always finding it hard to join new divisions because i run low on groups i have to leave groups that i really dont want to i think this is a good idea

Being a vendor in SL, i'm constantly joining and leaving groups to be able to put vendors down in marketplaces, etc. I've had to cut all my friends "for fun" groups and am missing out on some funny stuff cuz of it.

Sim owners I know have had to create second avies just as group spill overs. It's nuts.

Hey, how about UNLIMITED groups??????

Thanks
Daeden.

Dzonatas Sol - Posted 16 MONTHS ago - 18/May/07
"... The limit was raised half year ago to 25. ... Don't expect more groups any time soon. "

Is it still too soon? My groups are mainly essential to business, there is no room for connections eg other creators, clubs etc therefore it curtails my involvement in SL, limiting me to simply running my own small part.

i voted on this last year, wish i could vote again.

Then the people happy with 25 Groups can keep 25 Groups, people who need more, like the land owners and the merchants can request a few more groups, and then there is no bias against basic members. I'm a basic member, but I've spent alot of money buying Lindens so I can buy nice things in SL, and I'm sure there are many other people like me, so it would be unfair to say our money isn't worth as much as premium members just because we choose to buy lindens rather than have the premium account benefit

I've got several groups tied up due to in-world training needs and being in the Wyrms Community. I heard that the Lindens can't give us more groups due to some kind of technical issue..I forget the details.

I'm using a free account but want to upgrade to premium when possible. Everyone's L$ is worth the same. Free accounts get stick because griefers use them to do what they do anonymously. There are many many free account residents who go about their Second Life peacefully, including those who are disabled in RL and haven't access to the cash go to premium. They get great benefit from the therapeutic side of SL ) .

(original comment follows)

This is obviously a notoriously bothersome issue for many of us. As a businessman, I have had shops in over 100 different Sims in SL... with as many as 80 running concurrently. When I decided to expand my own facilities to rent to others and take on a staff to run events, I found myself in the all too common place of needing 3 or even 4 groups to effectively manage communcations and land rights just for my own store. 100 groups would have been nice... 25 is just flat not enough for those of us who are extremely invovled in one aspect or another of SL - be that busines, education, culture, or whatever. Casual users can scrape by with 25, I suppose, but it it quite an inconvenience for me on a near daily basis to be limited to 25.

I always assumed there was a technical reason for this, however:

Tonight, I heard about a 3rd party viewer that supports 100 Groups. It is apparently targeted at Opensim users, but I learned of it from some SL Residents using it for Secondlife.

((I didn't see anything that said dont post URLs, so I hope this isnt a fau paux)) http://opensim-viewer.sourceforge.net/

It's called the Hippo OpenSim Viewer (as near as I can tell it has no connection to HippoTechnologies). It claims to be a derivative of the 1.20.15 LL Viewer.

I haven't done much testing on this aside from looking into the group limit (which does seem to work, though I cannot vouch for any stability in the viewer). It does beg the question, however, if a third party can get access to 100 Groups just by reconfiguring he Viewer, what's the hold up on this issue?

From the Hippo OpenSim Viewer web page (http://opensim-viewer.sourceforge.net/)

"NOTE: This viewer can connect to the Second Life grid, but there the usual limits of Second Life apply."

That means the group limit is based on which grid you connect to. if you connect to the real SL you get 25, if you connect to another grid that allows for more, then you get more. The viewer simply allows 'up to' 100 groups, but it's the server that really caps you.

My question is....what's the bottleneck? What's the high DB stress here?

The group list stored for the Avatars? Hardly. It doesn't matter much if 25 or 50 group IDs are referenced there.

The amount of avatars in a group? Well, not when looking at a single group. It has to load a whole mass of Avatars either way.

The overall amount of groups and Avatars in them? Perhaps. That's the only part I can see where LL sees a technical issue, when it comes to the Group database as a whole.
And seriously...I'd love a technical explaination by a Linden who's in the know. Seriously guys, just tell us the exact technical problems, tell us that 'it won't be changed anytime soon due to time/effort, and that's we'll be informed when it happens. But don't just leave us hanging for years without any detailed statement, especially given that the code itself is pretty much ready.

• I know this because I was, as a matter of fact, in more than 25 groups yesterday. whistles

That limit isn't likely to go up much in the near future until we've got a much better solution for group chat, or until groups are reworked so that every group doesn't include chat.

Yes, I remember the talk about IRC and XMPP on SLDEV, tho I pretty much connected that with group chat lag more than any actual group membership limits. Again, much appreciated.

P.s. I think alot of group owners would love being able to create groups without chat features. There are lots of announcement groups for product updates that purely work by notices, and where group chat isn't welcome.""

***

This is exactly the point for many people. Speaking for myself, I am a business owner that caters to the medieval RP community and has various store locations. Since a lot of market areas are on land that requires group permissions to build, I am constantly capped on my group memberships (a handful of land groups for business use plus the rest for personal use), and am also therefore restricted on where I can strategically place shops because I have no room to join another land group, or am forced to drop a group that's already important to me in favor of another. These land management groups do not require or utilize chat, or even use notices... their purpose is solely to manage build permissions. I understand the data load that chat functionality creates for, say, 1000 groups of 1000 members each at any given time. It's MASSIVE. But why, since fully functional groups already exist, would it be so difficult to create a scaled down category of groups that are for things like land permissions only, with no chat features? I don't expect that we would or even should have access to a limitless number of groups of this (or any) type, but certainly with a new class of minimum-feature groups, we could be allowed a certain number of memberships of that type in addition to the 25 full-featured groups. Even an allowance of 25 in each class would be a vast improvement.

And by the way, I understand that I could create alts to have access to more groups, but I don't see that as a viable or permanent solution to this issue. Yes, it might be considered a workaround, but the core problem would still exist, and people creating more and more accounts in SL simply for the sake of managing their group memberships (which I'm sure does happen) is certain to contain its own set of data load dilemmas, just as camping alts do.

Excellent comments! You really got me thinking and I might have a solution, although not being a programmer - there could be unforseen obstacles... but here goes:

As group 'communication' consumes a lot of system resources, why can't we have two types of groups, as follows:

Group Type I - Existing format, no changes.

Group Type II - (To be developed) - for Identification use only, NO COMMUNICATION AVAILABLE. This group would be for merchants, deeded land, just about anything where it is clear from the onset that the only purpose is to be able to wear a tag to grant you access and/or permissions.

It seems to me that a group that does not require or allow any communications would not burdon the existing system and there are many residents who don't even allow communications in their groups now!

Hope the Techie Squad is listening, maybe we have something here???

I second dragonlady majestic's proposal of a second type group and I think it would be the solution for the group's limitation, as the GROUP CHAT option is the issue that limits the actual groups to 25. Some Abilities like Parcel Management and Object management could be transferred to the second type Groups.

We have to see what is the opinion of our Lords, the Linden.

Rui, Radioactive Rosca

A search on xstreet will produce one time low cost solutions that do the same thing but with a tad more effort.

However these IM systems send green text IM messages that some people think is unsolicited spam even though they opted in. So you have to read the riot act about how the recipient opted in and how to opt out in every message you send out. Otherwise you get ARs filed on you for spamming.

We need 2 types of groups. One for communications and one for land. And both types to work and not burden the grid. Unlikely to be happening anytime soon.

But we can hope anyway.

I also do like the idea put forward about users having to upgrade to premium for the extra groups, would get more users upgrading, and more money for LL. Although i would like it to be free

1) rp sims. each rp sim/cluster for non admin can easily use at least 4 groups. overall group, racial group, faction group, renter group for example. if youre an admin you may have to join many more groups.
2) clubbers. even if you dont work clubs, if you visit allot of clubs you ovften need to join the vip groups for each that you want to join the contests of.
3) venders/store owners. each place you want to put a vender genrally makes you join a land group. currantly this often means allot of store owners ahve 3-4 alts devoted solely to placing venders
4) club, store, business, etc workers, each ent business usually ahs a seperate vip or info gorup and a staff group. usually if you work a place you have to join both. some stores still ahvent made the switch to subscribe o matics yet.
5) for me i have a business group for my own business, a family group, two clans, two seperte fan groups, and then several rp groups and staff groups im in. the vip ones i am forced to rotate between.

So we simply need more groups immediately. Someone that opted in a group by becoming a member cannot file spam abuse reports. Or if they do they should be immediately suspended for filing a false AR since they opted in to the group.

So the need for more groups is increasing.

Again we need a new type of group called communications groups that have nothing to do with land permissions and land permissions groups as currently exists.

I am Constantly having to re-invite performers, and vendors simply because they do business in more then 25 locations. groups of this nature NEED to be unlimited, or as close to it as we can possibly get. there is no other solution that I can see here. Subscription services are well and good for simple ONE-WAY announcements, and I have one for customers of my mall to announce events and specials, but groups have gone WELL beoned what they were originally intended for.

Maybe the solution is to only allow LAND owners to create groups, now before you start flaming me hear me out. What we need is a communication only group. It would allow anyone with $100 to create this group, it should have more then 1 person in it to exist, and could be configured to allow open communication between all members, or restricted to an owner specified list of AV's. if you mute a specific AV, it should also mute them in all the groups to which you both belong. Since its a very simple feature you should be able to have as many of these as you want. The other kind of group would be like what we have now. Its main purpose is to control a parcel of specific land, and can only be created by the OWNER of that land. The owner could designate other AV's as "owners" making that land automatically group owned. The original owner would be automatically responsible for 100% of the expenses of the group owned land unless other owners designated a willingness to assume part of that obligation. if the original owner sells the land he can elect to sell it with it, or dissolve it. all owners would have full permissions over all the aspects of the group. roles could be created just as we have now. Since this is a far more complex feature, it should be limited to say 500 per person.

I'm sure there are other ways to handle this, but the important thing is it needs to be handled NOW... either come up with a way to split groups up so we can have more, or simply give us more. and not 10 or 20 more... A LOT more.... SL is a big place... we need to be able to participate in most of it, or whats the point. this has been opened since MAY 2007 its now 2009, No one is assigned, no progress has been made, and its the NUMBER ONE issue in server jira. If I dragged my feet at work not doing something my boss asked me to do for this long, I'd be one of the 4 million out of work people. faster then you can say rolling restart. lets get this done before we introduce any other new features,.

Something like the Ban-List, but for giving Building-Rights.

So Vendors won't have to join a group for each single shop anymore.

Lets remove Land permissions and roles from groups COMPLETELY.... lets make it part of the Parcel control. We can have Roles, permissions. All controlled through the about Land. These configurations could be assigned a unique name/UUID that could be replicated to other parcels & sims

Roles would simply be lists of AV names and each role would have a matrix of allowed and not allowed options. This would not be carried around by an AV... It would be carried around by the Sim

Groups on the other hand would simply be a collection of people with a similar interests. The only option to these groups would be is posting allowed only by the owner or by all members of the group.... if by only the "Owner" then there would be a list of AV's that are "owners" and therefore allowed to post comments. We would also retain group notices & proposals using this same permission schema.

For example, Freestyle uses two groups – one for notices from vendors and other group activities (like buying stuff cheaper) and one called FreestyleChat which is basically for anyone to discuss freebies in SL. They've done this because the functionality of a notice & perms group is very different from a spammy chat group.

I for one don't need Group IM capabilities in my own group – it's strictly for notices and group perms on items. 90% of my groups are oriented towards perms & notices. Only a few are all-purpose notice/chat/perms groups.

exemple:

[YD] Production
recive same im and sam note card with this link option, even if you do not have the [YD] Studio
[YD] Studio

and you could not see or with special permission add ability group , same of email link ton hotmail options* if you understend this

Al the time i here Linden say how great it is , that Linden provided the platform and the resident's Premium ore not, made second life what it is today.
Something that's as great , if not even more great than the internet it self.
BUT, allot of us , and i'm speaking for people invomved in keeping alive the music and live music in second life.
We all do our best that this will happen , even it's nor easy with the prices, but we do it. But people that own venue's and clubs, education misuc schools.
They get every time the same question of al the live performers, and that are live artist's, live DJ's and Live VJ's to become a member of there fanclub.
As a education music center, venue, ore club owner, its not nice to have to say no, specialy because these people keep the live music in second life alive.
So if you can make an onlimited friendlist, where more than the half of the people in the friendlist even left seconlive alredy long time, and is still in your friend list.
Why not make the friendlist like lets say limited till 100 friend's and the group list's un limited. That would be better for all of us i think. Because dear Lidens it is really not
easy to keep the music alive. Dont forget that al concerts and performances are free, but the club and venue owners still have to pay the artist's, the tier and so on.
So is it so much what we ask ? Just do something at the groups limit, and show that Linden is suporting and apriciating what music education silms, venue's and club owners try to
do day after day , some of us even 24/7. S it would be nice to feel for a change that Linden care about what we try to do.

And believe me dear Lindens it is not only the music part os secondlife that need this, think also shops , creators and so on....

Thank you

With musical greetings

Amber Ashton

What I can do, and would really like to do, is offer help. I'm a systems administrator with 15+ years of experience. And guess what...I'm not alone! Imagine that...other systems administrators enjoy second life too So...I'd say start a group of systems admins so we can all get together and offer help, but oopse...my groups are full, so there's goes that idea.

In all seriousness, I'm relatively local...santa cruz, california. Do I really have to be a Linden to offer help with performance issues here? You Linden folks have my contact info. Call me. I'll take a day off, drive up to San Francisco and we'll spend the day having fun doing systems stuff.

Sincerely,
Science Copperield

PS: Just to let you know...what I like least about Second Life is still 1000 times better than what I loved most about my last virtual world...which wasn't World of Warcraft...and which I won't mention because I don't want to give them any press whatsoever.

http://jira.secondlife.com/browse/SVC-1509 there is one.

https://jira.secondlife.com/browse/VWR-1298 is another

https://jira.secondlife.com/browse/VWR-2950

Well it is important. If you don't want us running 20 alts just because we need the groups, then you are going to have to start doing something.

I saw the one option... Add more groups to the premium members only. YEAH! Give us something special for what we pay more then just a little bit back. Give us this! Why not? Maybe just MAYBE you would get a LOT more premium members if you doubled the groups for "paying customers".

Also it produces a lot more strain on a PC or network to render a WHOLE avatar, their inventory and their groups then it would to just run groups on a single avatar. The whole reason people create alts normally is for advertising or group space. now that Linden Labs has made new rules about how many alts you can have people that run businesses such as real estate cannot maintain control by setting land to specific group

I am into real estate thru SL and each region has its own group so that my tennants can rez items, access the ban lists, change media settings, etc.

I also agree that when a group is "created" we should have the options to make it a notice only group, or to provide notice to specific titles in the groups, or to have it be a regular plane jane group.

Also it produces a lot more strain on a PC or network to render a WHOLE avatar, their inventory and their groups then it would to just run groups on a single avatar. The whole reason people create alts normally is for advertising or group space. now that Linden Labs has made new rules about how many alts you can have people that run
Kachina Duncan: businesses such as real estate cannot maintain control by setting land to specific group

I am into real estate thru SL and each region has its own group so that my tennants can rez items, access the ban lists, change media settings, etc.

I also agree that when a group is "created" we should have the options to make it a notice only group, or to provide notice to specific titles in the groups, or to have it be a regular plane Jane group. and I also think we should been able to add as many add as many roles we want to each group

and we should be able to add min of 50 groups and a max of 100 since most clubs and other place you need to have two to three groups and if you have more then one place you work at: say you work at 4 clubs and each give you three groups each that is 12 groups no and if you any advertising that could take 4-6 groups now you have place you go need vip room you have no now since SL only let you have 25 groups.

25 groups are good start. But they fill up fast. So my suggestion would be:

100 groups for premium members
25 groups for credit info on file, adult verified avatars, or avatars old than the day of change
10 groups for new no payment info on file avatars created after the date of change

This would immediate raise the value of mainland as a side effect

ciao,Kephra Nurmi

The problem: Such a change would require both a server rollout and would force everybody to use a new client, as part of the 25 groups limit is client based, and part is protocol based. 100 groups would requre a major release ! So I fear this jira will be delayed till Secondlife 2.0.

I also understand about network traffic so while this is somthing most SL Community Members need/want, if the Network and hardware (servers) are not up to it, there isn't much LL can do.

Soft made additionally a statement that they are aware of this issue. But Soft and Argent Stonecutter already explained the technical reasons why this probably won't finish.

I am more interested in stable sim crossings than in infinite number of groups so I don't vote on this issue.

sarcasm by the way, its not the most difficult thing in the world to add more entries for groups. Linden, try use google and search for tutorials if you are stuck.

http://download.oracle.com/docs/html/B12034_01/ch5_admi.htm