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.