Yet another suggestion for structuring the new group tools

One of the challenges we face while discussing "Future of Groups in Second Life" seems to be the different applications of groups in SL and the different resulting points of view, IMHO. Groups are used for social clubs, as mailing lists, as a way to form a rudimentary corporation etc. etc. and nearly any concievable combination thereof. All these groups of residents using the Second Life groups have different ideas about the perfect tool called "group". It is my belief that all of these different "users" of the group tools could be made happy (well, at least more happy) with a set of functionalities and many flexible ways to combine them.

Let's have a look at the basic areas which the group tools cover, first:

1. Rights and permissions
   
2. Decision making
   
3. Ownership
   
4. Communication

The challenge in trying to setup a flexible, powerful and secure system involving at least some of these funtionalities is in no way new. Many software systems need such functionalities and there are proven solutions or models for combining them in a straightforward way. You can find such models implemented in many collaborative systems; especially in workflow automations tools.

But lets get back to the areas of functionalities and their current problems first.



Rights/permissions
The most important step towards more usable group tools surely is a more granular system for assigning and delegating rights and permissions. Currently there some three dozen abilities you can get by creating or joining a group. The following collection is taken from Midtowns summary and is not neccesarily complete:

1. Founding the Group
   
2. Naming the Group
   
3. Paying for the Group
   
4. Decides to Keep Open or Invitation-Only Membership
   
5. Decides to Make Public Group Name in FIND GROUPS
   
6. Decides to Make Public Members' Names
   
7. Invites Members
   
8. Expels Members
   
9. Invites Officers
   
10. Expels Officers (currently not possible as officer recall was removed)
    
11. Names Titles
    
12. Pays Purchase Price of Land When Buying for Group
    
13. Names Land and Describes Land
    
14. Puts Land in Find Places With Check-Off ($30 Fee Debits Equally from All)
    
15. Puts Classified Ad on Land Parcel
    
16. Sets Landing Point
    
17. Returns Prims
    
18. Parcels Land
    
19. Sets Music/Video Stream
    
20. Sets Land to Sale to Anyone Out of Group
    
21. Puts Land to Sale to Specific Person
    
22. Takes Land Out of Group Through $0 Sale to Self
    
23. Accepts Deeded Land Contributions
    
24. Announces Events on Events Calendar
    
25. Deeds Objects
    
26. Collects Portion of Membership Fee
    
27. Sets About Land Options (Edit, Fly, Outside Scripts, Damage, Create/Edit, Landmark,)
    
28. Starts Election to Move from Member to Officer
    
29. Pays Tier Contributed to Group
    
30. Announces Events on Events Calendar
    
31. Sets Home to Here on Group Land
    
32. Makes Proposals for Votes
    
33. Makes Group IMs
    
34. Collects Portion of Income
    
35. Collects Portion of Dwell
    
36. Leaves Group

Maybe (probably) this list has to longer. But I don't want to discuss this details here.

The biggest problem with the current group tools is the fact that specific sets of these permissions are given to three different groups of members: the founder, the officers and non-officer members. And some of the most powerful permissions are given to all officers. So every officer can take out (buy for 0 L$) group land for example and kick out any non-officer member. Delicate. (Prokofy made a nice blog post about this talking about "Imagine if the Pizza Guy Stole LL".)

Thats why I - and others before me - think it is unavoidable to be able to assign the permissions on an atomar level. The result could be someone, for example, who is able to terraform land or set the media stream for a parcel of group land, but can not change the price of that parcel; or someone, who can invite a new member, but can not expel members. etc. etc.

Of course, this would result in a new permission called "Be able to set the permissions of some other group member".



Roles
Setting the rights for every new member on an item by item basis can become a very tedious process; especially when the list of possible permissions gets longer. And it will become hard to keep an overview which group members have which rights and how the combination will affect their abilities in the group.

The proven solution for this challenge is the idea of Roles. A "Role" is a collection of rights that is assignable to a group member in one step. For example we could have a role called "Junior Officer" which includes "May invite new members", "Terraform Land" but not "set for sale" or "expel". Convenient.

Of course, this would result in a new permission called "Be able to define a new role" and "Allowed to assign a role some other group member".

The atomar assignment of permissions alone will correct many deficiencies of the current group tools. Introducing roles would keep the assignment and management of permissions efficient.

Implementing a full role-based permission system might cost an effort that is more than LL currently plans to spend on the renovation of the group tools. A simpler solution might be to have 4 or 5 different types of group members (not only "Officer" and "Member" where each can have a different title and set of permissions.



Decision making
The only support for decision making SL currently supports is the group vote in which every member has one voice - and the result is simply a message to all group member telling is, if the Yes-votes reached a certain limit. This is unflexible, too. If you look at "real" organisations there are all kinds of decision making processes from dictatorial regiment, majority votes to unanimous votes, with veto rights and so on.

I would like to suggest, that the new group tools at least would offer the possibilities to vote for some decision inside one sub-group (all members given a specific "role"; see above), to still set the quorum to anything between "one voter" and 100% and to weight the votes.

For example it should be possible to define the quorum for a vote inside

1. All group members
   
2. All group members voting this time
   
3. All officers
   
4. All officers voting this time
   
5. All group members who deeded some land
   
6. ...

Votes should be able to be weighted by

1. One resident one vote
   
2. Tier deeded
   
3. Other way to define a "share", maybe by "amount of entry fee"?

If such a flexible system would be implemented and combined with the above-mentioned system of role-based assigment of permissions, you could model nearly every form of First Life "group" from a social club to a corporation with just one simple model by combining the options. (And if even multistage votings would be implemented, one could even model "checks-and-balances" types of organisations. But that probably would be asking to much for 2006.)

To be continued ...


DISCLAIMER A: This text in no way tries to define a perfectly thought out and checked solution for the "new group tools" problem. It presents only ideas tried and tested in other realms of IT-based human collaboration.

DISCLAIMER B: I don't claim that the ideas presented here are "original". I am rather sure that many have been presented in similar form in other threads on the forums. I am very sure that they can be found on other sites in the web (as I have said: they have been tried and tested elsewhere).

As an extention to your 'atomar' permissions, setting perms on per person per parcel basis would also be nice.

Imagine you're a land baron in the rentals market. You rent parcel A to renter a, parcel B to renter b etc. Currently if someone spams the territory with prims an officer has to go and sort it out, or set autoreturn (which also has issues with guests etc.).

But if I can set renter a to have rights to return objects on parcel A only and so on, then I've got around a potential headache. I'm actually in the situation where I rent a few parcels to friends, so it's not really a nuisance for me, but if I'm away for a week as might happen they can have a plot full of someone's else stuff for that whole period...

It's close to the microperms idea and some others, but should be added to list of things we'd like to see I think.

Eloise, of course it would be nice to be able to combine permissions and "ownable" objects (I am thinking of objects too and not only parcels of land) on a very atomar level. This has been described very detailed by Tiger in his suggestion. I am not sure if Aaron intended something similar with the term "Unix style permissions".

Given, what Travis told us about his experiences, though, I am not too optimistic, that LL will overhaul the complete permission system under the topic of "Group Tools" ...

I agree, which is why there's a thread I started for a minimum acceptable patch level. Discussing both a 'would like to see' and 'real minimum to be useful' strategy might let the dev team work on one then the other for example, so that eventually we get to the right thing and we can accept it will come as long as it's improved stepwise...

I'm hoping that we can work out some sort of road map that moves us from now to the ideal... Not all at once, but in stages. It's an obvious first step to start with granular permissions for groups, then build from there to, eventually, land and objects.

It doesn't have to be all-at-once, but knowing where you are headed makes the near-term turns easier to make... Less backtracking later.

I like your ideas, Pham (they are quite similar to mine ) except for the decision-making part. You are proposing a more in-depth and complicated voting system. And while that will expand what can be done along those lines, it doesn't throw it wide open, or even just wide.

It might be best to leave such systems to scripts (if scripts can be improved with regard to inspecting and manipulating group properties and membership lists) where any level of simplicity or complexity can be achieved... As it is needed, and not all up front using the Linden Lab crystal ball to design from.

Just a thought.

Such a road map obviously will be a neccesity. I am not sure how much influence residents will have on it, though.

I is not completely clear to me, what you mean by "start with granular permissions for groups, then build from there to, eventually, land and objects" exactly, Tiger. If I got it right, one of the major challenges the current system of Group Tools is facing is exactly "land". So I guess it would make sense to include some improvements for groups with shared land ownership in the first step ...

Thank you, Tiger. As you might expect, I don't think the mechanisms I proposed are that complicated.

If you bring it down to the basic ingredients I was only suggesting (with some little additions), that
(1) Votes can be "weighted" (by tier contributed or some other attribute)
(2) Votes can be restricted to a "sub-group"
(3) The quorum can be defined as "relative to the number of people participating"

Introducing these options (I did not suggest to throw out the old basic-democratic voting system), would greatly enhance the flexibility of the voting system and make it possible to model many kind of "groups" we know from First Life.

Coming from an IT background myself I would like to agree with your preferences for a more "programmable" solution. Given the history of Linden Labs very careful and conservative handling of all LSL functionalities involving payments, land, permissions and ownership, I doubt it if we will see fast improvements in that areas.

There is a reason for that, too. As soon as you have these functionalities "scriptable", you get many, many additional issues in the areas of security, dependability and trust. Lets not forget that there is real money involved with some of these questions. And people tend to get very sensitive and suspicious, as soon as money is involved.

Trust is an important issue whenever multiple people get together for a common purpose. I dribbled about this very topic in my latest entry, Voting, Trust, and Accountability… Oh My! I plan to dribble more about it as soon as I've thought up more juices and maybe absorbed some more from the forums.