CUNY Academic Commons

The only data we have to sort by is already implemented (alphabetical, most members, most recently active, most recently created), and we don't have any structured data at all to filter by. So this ticket is only possible when something like #253.

In any case, building a taxonomy system for groups is a mammoth undertaking, so I'm proposing we find a milestone for it other than 1.4.

moving out of 1.6 to 1.7

I feel like this should get feedback from the larger group since it should reflect our larger agenda on how we expect people to think about the relationships between groups and in some ways categories of thought and activity on the Commons should be organized.

Worth pursing, but there's a fair amount of work that needs to be done to describe the workflows, as well as the various ways in which group tags would be displayed. Maybe we can look at this in an upcoming release.

Per discussion on the CBOX-OL project, let's use the work we've done on the Group Categories plugin on that project to bring this over to the CAC

I started working on a first-pass integration of the group category plugin on the OpenLab with the Commons, but I ran into a couple of technical hurdles. Since the task will be non-trivial, I'm going to spell out some of the questions using screenshots and info from the OpenLab.

a. Integration into directories

The OpenLab has a sidebar on group directories where you can filter/search in a unified interface. We don't currently have anything like this on the Commons: our "Order by" dropdown is in a separate space from the search UI. Assuming we want to allow for browsing/drilling-down by category, we'd need to have a selector somewhere in the directory interface.

b. Appearance on group pages

The OpenLab has a pretty heavily-customized interface for groups, which includes a tabular display of group info (like description, admins, etc). This is where the category appears. We'll have to come up with a place to show this data. And given that we are already putting more content into this space during the 1.12 release (see https://redmine.gc.cuny.edu/attachments/download/6450/Screenshot_2017-09-27_15-03-28.png), we might want to consider a slightly broader rethink of how group headers look and/or how their metadata is displayed.

In addition, the OpenLab doesn't link the category name group headers, but I think it's a decent idea for the category name to be linked to a group directory, filtered by that category. Not critical, but something to think about.

c. Management of categories on a per-group basis

When editing/creating a group, admins can choose from a pre-populated list of categories. They can pick more than one, but there's no free-entry space for them to create their own categories (it's a controlled taxonomy). The OpenLab has a totally customized interface for group creation/editing, so we'd need to figure out (a) whether we like the checkbox interface shown in the screenshot, and (b) where it should go (ie, in a new group creation step/tab, called 'Categories', or perhaps appended to an existing step)

d. Network admin management

This is a screenshot of how network admins set up the categories. I think we can pretty much use this one as-is.

e. Blog categories

In the future, we want to introduce blog categories as well #6078, and ideally, blog categories would somehow integrate with group categories. (Maybe they'd be the same thing?) The way that this plugin is built will make it somewhat complicated to make this integration happen - though, to be fair, there's no obvious way to make it not complicated. It's likely to complicate the implementation if we try to do it all at once, but we might want to at least talk about how site categorization would work in theory, to be sure that the decisions we make about group categorization don't preclude future integration.

As a side note: implemented correctly, this would be a really valuable contribution, either to BuddyPress itself or as a standalone plugin. I'd likely want to rethink some of the data storage mechanisms if we were to move in that direction (especially BP core) at some future date.

Let's talk about a broader vision for what these categories should be accomplishing, especially alongside #6078, and then we can start drilling down to talk about how some of the OpenLab interfaces described above can be implemented on the Commons.

This is a possible big feature for the 1.13 release, alongside onboarding stuff. Let's discuss during an upcoming meeting.

There may be some overlap between this ticket and the "primary purpose" field being introduced in #10987. This overlap is good insofar as it provides some of the sortable/filterable metadata asked for as part of this ticket. It's bad insofar as it threatens to confuse and cross purposes between the very limited "primary purpose" and the more general concept of "category" or "tag". Let's sort the "purpose" out first, and then figure out how what's requested here - say, something more folksonomical? - might fit alongside.