Support in the future for Subgroups? (nested groups)

Most large organizations contain hierarchies within it.  Corporations have divisions broken down into departments and into groups or teams.  I believe mapping these into groups within elgg will help with its adoption in these organizations.

I believe there is already an extended group community plugin that has implemented a portion of this but perhaps does not go far enough.

Thoughts?

 

  • ;-)

    This has been been a "contention" point before.

    I do believe that CurveRider/ Elgg.org/Dave/ et al might be too not sure whether to compartmentalize Elgg just like the other CMS's that have preceded or go with the flow.

    That said... should Elgg be just like any other other CMS ? Or be what Elgg is... "extensible" forever...

    This "extensibilty" is the primary aspect which feel I do not wish to "violate".. because that is what gives me the power to expand, rather than being bound....

  • Ok - I think I know what you mean from one of the other discussions.  Keeping the core "pure" and allowing the plugins to provide the functionality perhaps makes good sense? Sorry - maybe its late in the night for me. Is that what you mean?

  • Agree, flexability is a must, this includes, If I wish to make it, I can.

  • @Alex

    some basic hierarchy capability... within the the core ( that can be elgg-extended) should do well.

    I wonder if Dave T is watching this one...

  • Bump for sub-groups. It is a very important feature for us!

    Have there been any developments in this space?

  • The way we acheive this is simple:

    1. set the container_guid of the subgroup to the guid of the supergroup. 
    2. implement a hook that joins the user to the supergroup every time a user joins a subgroup.

    What else is there?

  • Can i bring this back to the forefront of the roadmap please.

    It is being discussed here in plugins

    http://community.elgg.org/mod/groups/topicposts.php?topic=569553&group_guid=7

    What I would like to see is entities be far more managable at the core level.
    such as naming abilities and creation of several seperate Elgggroup entities.

    Can not a config file be built into Elgg that labels each of ALL the entity names? then those label codes are written throughout Elgg. Although I am no coder, it's how I have seen software written. There is too much to write here that I feel it could be set up, but it doesnt stop there.

    Yes I realise the amount of work this would require, but imagine the possibilities!!! Full customisation with ease, well for the user hahaha.

  • Just a small thought about sub groups.

    I am thinking about what a group is and what is it for rather than the technical possibilities. A group is simply a group of individuals that have commonality and wish to share that through a series of tools - discussions, blogs, wiki, file repository, that sort of thing.

    Socially speaking, a group is not a hierarchical thing, it is a peculiar entity that only has reference to itself in its most basic form. It would have a hierarchy within it - Owner, administrator, moderator, member, and possibly further invented roles (see here) - but it does not naturally sit within a broader hierarchy.

    Therefore, the idea of a subgroup makes little sense - what that subgroup would be would be another, separate group.

    Now, two groups may have a relationship to each other. This could be expressed in several ways: a forced alliance between two or more groups, or overlapping interests creating mathematical sets where groups might share some but not all interests; especially of interest in a purely social website.

    A Hierarchy of groups and subgroups is a too rigid a structure and does not allow the relationship of one group to another to change, which socially speaking would be an unnatural state.

    Since Elgg allows a user to belong to multiple groups, then there is no need to create a sub group structure. However, group affiliation, both vague and rigid, could be created where joining one group would automatically join you to several others.

    By adding a very powerful and flexible role system you can make it so that a person joins one gourp at one role level, but would have a less powerful role with the affiliated groups - for instance, they could have read/write privileges on the primary group (the one they joined first), but read only on the affiliated groups.

    In a company structure, for instance, you might have a group for Engineers. Some of those engineers may want to create a seperate group to research batteries. With a hierarchy, if that new group is a sub group, then logically all members of one would be members of the other. However, as part of the research, the battery group needs financial involvement. The Accountants group is part of a completely unrelated hierarchy - and suddenly it does not work.

    With a non hierarchical design, the battery group is an independent group that has members made up of both people from the engineers group AND from the accountancy group. However, because of group affiliations, Engineers and Accountants who are not active members of the battery group can still have access to parts of the battery group should that be desireable.

    Now, that is a proper and effective way of utilising groups as it reflects what happens naturally in society.

    This sort of structure also means that no group is demoted or promoted in the perceived hierarchy purely because they are the subgroup of another - within a company, that is the perfect way of putting someone's nose out of joint!

    Groups should not be treated like categories - they should be kept so that they have an individual identity even if they do have an affiliation to another group.

  • @Joss

    the beauty behind different functionality, or the possibility of different functionality, is the ability to step away from something completely generic and form something unique. 

    This is actually one of the motivations behind why I put together supergroups. While I wouldn't think of this as sub groups in any particular sense, it can still be very useful to have to the ability to organize certain structures so that it becomes easier to get to the content a user is looking for. 

    Personally, when I think of the concept of sub groups I think of teams. There is a hierarchy which suggest a container for several related groups who might ultimately be working together on one specific goal. The container, which would be the broad group, would define the overall reason for existence and those sub groups, or teams, would reflect smaller parts which aim to achieve the focus of the whole. 

    Of course this might be better understood if Elgg was being utilized by an organization. To be fair, you are correct in that since groups already exist there might not seem to be a reason to put a hierarchy in place. However, imagine a big university with different departments, different scholastic projects, and having these things organized together in a hierarchy. Wouldn't this actually make it easier for the end user to discover what it is they were looking for? 

    I admit if the goal is to duplicate or mimic the structure of a site like Facebook the probability of creating such a hierarchy is unnecessary, but what it really comes down to is what is necessary for an individual site. There is really no right or wrong in regards to this until knowing the need of a specific site. 

  • Interestingly, I also play with Liferay. Liferay uses Organisations as sort of global entities and the Communities as the equivilent of groups.

    Because the community structure is highly customiseable (you can create as many roles as you wish within a community) and, like Elgg, a user can belong to more than one community and have a different role within each community, many users are finding that they are hard pressed to find a use for organisations.

    It is one of those things that if your draw it on paper (still the best way to do this!) the temptation is to draw a circle around groups of groups or communities to create hierachies. However, you then have to ask the question, why would you want to collect groups together technically in the first place, apart from it seeming to be logical?

    I think the point is that not every direction of social interaction needs to be reflected in the sofware architecture. For instance, two groups can say they are friends with each other - but it is arguably whether that actually needs to have any application to create what is purely a social bond.

    I would be interested with your plugin to see a few written examples of how Supergroups would be used - both as an administrative tool and what effect it has on the community as a whole.

     

     

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.