CUNY Academic Commons

Thanks for the use cases, Matt and Luke. They give me a sense of how the data probably ought to be stored so that it's available for easy querying.

This discussion could dovetail with coming discussion of OpenLab abstraction... can we piggyback the collection of this data onto the downstream configuration that happens when you launch a course, project, portfolio, or group? I assume this functionality will be abstracted into CBox?

On the OpenLab, site types are inherited from group types, which works because all sites belong necessarily to a group. This won't work for the Commons.

To move forward, I think we need a sense of what a minimal user-facing interface and workflow would look like. Broadly speaking, there are three ways that this kind of data appears in UIs (I'll use "site type" to describe the content we're talking about):

1. Displaying existing site type. This could be in site directories, on single sites, in the Network Admin, etc.
2. Providing an interface for filtering by site type. This could be either public facing (commons.gc.cuny.edu/sites) or Dashboard-only (Network Admin)
3. Updating site type for a given site. There's a handful of places where this might happen: site Dashboard, Network Admin, somewhere in the BP interface

If we want this information to be fully public - kinda like "profile" data for a site - then all three items would have to be user-facing, probably somewhere in the BP interface. If we are primarily interested in internal data, at least at first, we might make it Dashboard-only, and we may even skip item 1.

These sorts of things are best built with one or more specific use cases in mind. A couple of brief narratives would be useful. Here's an example, totally off the top of my head:

The CUNY Academic Commons team wants to run periodic reports on how many groups are in a given category. Users will volunteer the "type" of their site during site creation, but thereafter the data will only be available to the Commons team. Queries will be in the form of an admin panel summarizing "type" statistics, which can be exported to CSV. Existing sites can be categorized only by network admins, via the WP Network Admin dashboard.

More could be said about this example - how should the summary data be displayed, for example? is the "type" vocabulary hardcoded or free-entry? etc - but it provides a framework for us to think about an inital implementation. Having two or three of these that are realistic (rather than plucked from thin air by yours truly) would help us to get a sense of what would constitute an MVP, etc.

Luke, can I ask you to think about this? If you can sketch a couple use cases - it's fine if they're invented, as long as they're realistic and specific - I'll be better positioned to estimate scope and so forth.