Groups

In effect, groups are collections of users that inherit shared permission on some data or maps. Being a group member is a bidirectional relationship requiring approval from both parties.

Different groups organize in different ways so the best thing to do is make group permissions simple and straightforward and let policy or norms do the rest. This proposal calls for three types of groups—public with open membership, public with membership by invitation, and private with membership by invitation—and a simple two–tiered member hierarchy:

• Managers may edit information about the group, adjust permissions, manage members.
• Members inherit permissions on maps or data from the group.

Some will make the case that groups should support sophisticated permissions systems and workflows but, while this proposal does not preclude adding such features in the future, it's important not to overcomplicate the situation early on by attempting to impose a presupposed model for how users should collaborate via the software.

1. Non-member View

To a non-member, a group appears in much the same way as a user profile, but with the addition of a "Join" button (1.0 or 1.1, see also 2.0 and 3.0) and a description of the permissions (1.4) below the About content (1.4). The summary and permissions information (1.2 and 1.4, see also 2.1, 2.4, 3.1, and 3.4) should be dynamically generated; and the members (1.5 and 1.6) badges should show a reasonable subset while providing a link to a full list view via the headings. Across all views, the "Maps & Data" list is populated by data or maps which explicitly grant the group permissions to view or edit.

2. Member View

The member view divides the member list by role (2.5) and allows actions (eg, messaging) (2.3).

3. Manager View

Consistent with the idea of " one interface", the manager view exposes options for editing descriptive content (including group name and profile image) (3.2), setting the group permissions/privacy (3.4), managing members (3.9). The Members section (3.9) sorts the list by actionable items (eg, requests to join), member role (ie, managers to near the top), and pending memberships (eg, invitations awaiting approval)—this is subject to alteration depending on implementation or further consideration. The options allow multiple members to be removed at once and allow for invitations and role changes. Requests to join can be handled in batch via role changes (3.8). Roles changes should preclude a situation in which there are zero managers in a group.

Possible Future Directions

Publishing

After exploring different possible models for how groups could work in GeoNode—aggregation, endorsement-based, groupware-modeled, etc—I went back to basics and considered a collections-based model similar to the way  Flickr organizes groups. In effect, groups are collections of users with permission to post data or maps to the group subject to post-facto moderation from managers/moderators/etc. Note that, unlike following, being a group member is a bidirectional relationship requiring approval from both parties.

Publishing would add the following abilities to each role in the member hierarchy, optionally adding a third-tier for content moderation:

• Managers (and Moderators) may add maps or data, remove any maps or data, or modify maps or data which they have added.
• Members may add maps or data, remove maps or data they have added, or modify maps or data which they have added.

• Non-member View
• Member view
• Manager view: Adding or removing maps or data (3.3 & 3.9)
• Add maps or data: Adding maps or data to a group is triggered from the Actions section (2.3 or 3.3) of the sidebar.

Endorsements

Previous wireframes included the idea that groups could 'endorse' maps or data sets to include them on the  group profile and have that show up on the  map info or  data info pages. The add workflow proposed above makes the first case redundant but there may still be a place for the second depending on the direction the software takes.

Fancy Permissions

TBD