Let’s create teams for real, it solves several issues
Currently, the LOTE4 teams are modeled as tasks, which confused @Alberto already, so probably many others. This modelling came to pass because what is now “teams” was initially presented as “big tasks to pick from to contribute to the conference … but just seven selected ones to not overwhelm new users with details”. This modelling is admittedly not ideal, and is also the exact issue that prevents us from implementing @Ben’s proposal of per-team task lists. Because, a task cannot reference another task …
Solution proposal
So I looked around in detail, and I think I found a clean solution. If nobody objects, I would try to implement it tomorrow as follows:
- There will be a content type "Team", and it gets the "Group" behavior from the OG (Organic Groups) module just like "Project" has now, but also the "Group content" behavior by which it can be associated with Projects itself.
- But you won't see teams among the list of projects to choose from when associating content (like tasks) to projects.
- Instead, a new Entity Reference field will be added to tasks (and only to tasks for now) to reference group entities of the "Teams" bundle.
- When associating a task to a team, one will only see the teams associated to the task's project in the options. There is a nice filtering technique in Drupal that can do this. (In addition to that technique, I would use the og_group_ref URL parameter as input for the group ID contextual filter – since this parameter is present when a task is being created but not yet saved, serving to prepopulate the "Projects" field then.)
Discussion of alternatives
- Teams as or per task category. The first alternative solution is adding a "task category" field to tasks like we had ("Technical task", "Design task" etc.). It would be a taxonomy term field, with possibly a hierarchical taxonomy, and possibly project specific taxonomy terms via either og_vocab or reference_option_limit. However, I consider this solution inferior because it does not really capture the usual semantics one wants to confer by tagging a task as, for example, "Design task": that it should be done by the design team. There could still be a Team content type, but as it would not be of the OG Group behavior type like proposed above, the connection to a task category would be informal, which again is poor (missing!) semantic modeling. So, for proper semantic modeling, teams should be a proper content type that can have members, allowing for example to send notifications about new content for the team with the OG notification system (and honoring the containing Project's notification settings).
- Teams as projects. The second alternative solution would be to use existing Projects for modeling teams. The advantage is that the UI for joining and leaving a team, and the notification system for new content, is already in place. But it clutters the Projects namespace to the point of utter confusion, as exemplified during the Spot the Future exercise, where in the end people resorted to cross-posting everything to all of the four or so STF related coordination groups
- Teams as sub-projects. The third alternative is modifying Projects so they can be sub-projects of each other (simple to do by adding the "Group content" behavior to Projects). However, this unnecessarily establishes the general concept of a "hierarchy of projects", which comes with complexity and uncertainty about how the hierarchy behaves regarding notifications, membership and navigation (we had subgroups in the original Edgeryders Drupal 6 site, and I found them confusing). I want projects to be a flat list, like in all other established project hosting sites that I know of, from SourceForge to Github.