All applications of this type have roles and I have noticed over many years a reluctance from developers to make too many roles or make the role system too complex. In more recent times there has been a move from many application (Joomla is a good example) to allow for a far more fine tunes approach to roles, admitting, perhaps, that in its initial design, the core functionality cannot and should not predict how or why an administrator wants the site to work in any particular way.

With my experience so far of Elgg (and I admit that I am probably missing many tricks) I have missed being able to create specific roles that are assigned very specific permissions. With Liferay it is possible to define multiple roles and to associate those roles to one or many portletts (Liferay plugins).

For example, every new instance of their forums can be set up to allow whether a specific role can post, read, edit, moderate, upload images, add attachments and so on. So, for communities (their versions of groups) you can create several layers of members in addition to the community owners, admin, moderators and so on, and then define what each of those can do on a community by community basis.

You can also decide which roles have access to which application (and to what level) on a sitewide basis that cannot be overuled by any local changes.

When setting up a system, therefore, if you wish you can carefully construct as complex a hierarchy of roles as you need, or you can just use the default ones which are pretty good already.

Translating that into Elgg, I would see it working in the following way:

The creation of clearly labelled default roles (some of these exsist already, obviously)

Global Roles - The Management!

• Superadmin role - can do and see everything 
• Site Administrators - each can be defined specific responsibilities. By default they can adjust settings of user facing plugins (but not plug ins that are for adjusting core functions) 
• Site moderators - Responsible for dealing with user and group administration and modetaion. 
• Site Editors - Able to post site wide news, bullitins and can create sitewide content.

Group Roles - from the user community

• Group owner - the initial owner of any group, whether they created the group or were handed owndership by a Site Moderator
  
• Group Administrator - this role can administrate a group but cannot delete the group or change its fundemental settings
  
• Group Moderator - a role that has moderation responsabilites for applicable plugins such as pages and forums.
  
• Group Member - a role that has read/write privilages on applicable plugins
  
• Group Guest - A group translation of a “logged in user” this role by default has Read Privilages but not write. If their read priviliges are removed from the group globally, then the group is effectively private (though not hidden).

General Roles

• Guest - a  non logged in site visitor. None the less they need a role so that what they can or cannot see can be set.
  
• User - the default role when a user first signs up (note: you should be able to create a custom role or choose another one of the existing roles to be the default role if required.)

All of these roles can be fine tuned and additonal roles can be created that have very specific privilages. For instance a group may set up two forums - one can be seen by guests, the second cannot.

When creating a complex role system such as this, it is important to give careful thought to the DEFAULT position. Programs such as Elgg must be as useable as possible out of the box and users will not want to have to mess about with basic settings just to get a site going!

Role Templates
Role templates are effectively SQL inserts that create a certain type of community. These would have preset settings for the default roles as well as any additional custom roles. These can be “installed” by the superadmin through the admin interface. Equally, a superadmin can export their particular set up for others to use.

This is especially useful for first time users who can use a role template to create one of a number of standard communities (completely private to all-together-and-pray-it-works) before they then start to fine tune.

Standard Role Interface. Every plugin would, by default, use exactly the same role interface. This is vital so that what every third party plugin is used, the way it is set up is recognisable adn familair. A Plugin Development Pack would contain the backbone permission and role system for developers to use.