Groups, Tribes and Projects in Pinax
From fairly early on, Pinax had tribes and projects. The intention of the distinction was that tribes are a loose grouping of people with a common interest (see Seth Godin's great little book Tribes: We Need You to Lead Us) whereas projects were more focused around managing a group of people working on common tasks.
This distinction was reflected in the differences in implementation: projects are invite only, tribes are open to anyone. Projects have tasks, tribes don't. But there are a lot of similarities: both have threaded discussion, wikis and photo pools. There's also a lot of duplicated code.
It wasn't long before I realised that really projects and tribes we just two subclasses of the same class (or instances of the same metaclass—more on that in a moment). So one of the things we're working on for the next release of Pinax is to merge the two into a single model but then allow a site developer to create as many differently configured subclasses/instances of this model as they like.
We haven't worked out the details yet, but basically it would allow you to define a new subclass/instance of "group", pick the membership model and what apps and object types can be attached to it.
Quite separately, I've noticed that there is another kind of structure that tacitly exists between tribes on Cloud27. I started a Python tribe but others have started Ruby and PHP tribes. There are also geographic tribes and language-based tribes. So there is another sense in which a set of tribes could be labelled as "programming language" tribes, or "geographical" tribes or "natural language" tribes.
So we have:
- the root group type (that will unify projects and tribes)
- types of groups (e.g. projects, tribes, other combinations of features and membership patterns defined by site developers)
- instances of one of these types (e.g. a particular tribe, like 'Python')
- a category of instances (e.g. 'Programming Language Tribes')
To slightly complicate things, one could imagine an "Australian Pythonistas" tribe. Or various intersections of "movies", "food", etc with geography-based tribes (e.g. Italian Food, French Films). These sorts of semantic relationships seems quite orthogonal to defining a type of group that has a wiki but not threaded discussions or is invitation-only versus free-for-all.
I'm trying to wrap my head around which to view as instances versus subclasses. As a longtime data modeler, I thought I had a grasp on this stuff but my brain is hurting :-)
Any suggestions for a metamodel?
Comments (11)
James Tauber on Nov. 9, 2008:
Yeah, that's probably a good way past some of the issues :-)
At implementation level, though, there's still a need to have a table/relation vs row/tuple distinction. Of my four, 1 could be thought of as a table where each row is a 3. 2 is a row in some second table not discussed here (the group type table). That still leaves 4 but maybe that's the one best thought of in prototype terms, particularly if the link back to the prototype(s) can be faceted.
Doug Napoleone on Nov. 10, 2008:
I would recommend going with the classic MUDD solution: an extensible template (AKA prototype thing Seo mentions).
I also first recommend working out how you want it to behave, then move that into a class/object model (it will change things), then figure out the best way to implement that in the tables. then go back and make sure it really does what you want.
The problem here is you want this to be all online/runtime determined at some level. Writing a custom model inheritance is not good enough for what you want for the framework. Taking things to that level is what hurts the head. You end up having to describe the table structure in yet another table structure. I have seen some dynamic model stuff but, 'that way leads madness'.
In the end what you want is a GCD of features. If people want to go nuts with customization, then they have the option of model inheritance. That way you could support plugin app style expansion; but the base should be enough for 90% of the people out there.
Down to the details:
split things into features, permissions, and settings. A 'grouping' (for lack of a better name) will have a set of features, permissions and settings (and a name). These could be via relations to other tables, but that does not really matter at this point. So you have a table detailing the groupings, from which you can look up the features, permissions, etc.
Then you have a table for the 'grouping' data... um.. grouping data, with a relation back to the 'grouping'. Where right now we have a table for the tribe data which is filtered on the tribe name, in this new world it would be filtered on a FK to the 'tribes' grouping, then the tribe name. The features on the grouping will tell you that it has a wiki, etc; the permissions will tell you its open to all, and the settings will control the details. This 'one big ass table' approach has its drawbacks for sure (just look at the internals of wordpress), but it is the easiest way to solve the problem.
The other option is to take it offline and require people to do things in code. This could be simplified into something like the admin where you create a 'Grouping' object via Tribes(Grouping), with the config. This could be done either at an app or settings level. This would allow for greater control from a programmatic standpoint, but increase the barrier for entry.
to be honest I have always preferred the latter approach. At the end of the day how many different types of social groupings are you going to want on a site? How often will this change (requiring it be something done live vs in code)?
Bob Haugen on Nov. 10, 2008:
See also
http://groups.google.com/group/pinax-core-dev/browse_thread/thread/0028939d542000b6
The grouping in Doug N's comment above is called OrgType in that discussion.
Tim on Nov. 10, 2008:
Hi James. You might want to look into your RSS feed. The links are not including your domain so RSS readers are having trouble.
Keyton on Nov. 10, 2008:
I'm also having some trouble with the RSS feed...
James Tauber on Nov. 10, 2008:
I guess the readers I've tried all resolve the relative URI but I'll look in to changing it.
Fitzgerald Steele on Nov. 18, 2008:
Forgive my ignorance...
Why not just leave it at a 'group' with whatever configurable parameters (invite/open, wiki/no wiki, photos/no photos) and be done with it? Leave it to the crowds to self-select groups, tags, etc. Wisdom of the crowds, long tail, and all that...
James Tauber on Nov. 18, 2008:
Fitzgerald, simply because which combinations make sense will depend from site to site. Not all Pinax sites are generic social networking sites -- some are highly specialized where the site developer might only want a particular style of group.
Gareth Simpson on Nov. 21, 2008:
So in that case, can't you just make the subset of group creation options open to the users configurable by the site owner?
Benny Daon on Nov. 28, 2008:
I like the design. It makes sense to have a metaclass group with no content. By using it as a base, my app needs only to setup membership and localization rules. Pinax takes care of the associated social network for me. Thanks!
I would like to see a scope field to create global and local groups.
I'm now planing a political pinax project - polinax - and I would be happy to base my polinax class on Pinax group. The scope field will make it easy to for polinax users to locate global moments and make friends with local activists.
Last Modified: Nov. 10, 2008
Author: James Tauber
Seo Sanghyeon on Nov. 9, 2008:
Don't think in terms of class/instance. Think prototype! :)