Community Call on Sept.4 - minutes

[katalin]

(this is just the first half, apologies for having to leave early) - pinging @Noemi and @Alberto for the rest and editing

Call agenda:

1. Curating the program: where are we with case study collection and invitations for session proposals?

2. Communications: Twitterstorm announcement is up, help spread it? Takes place Tuesday, Sept 16th, at 12 PM CEST.

3. Teams, tasks completion -> earning tickets. @Natalia Skoczylas is starting to issue tickets to Edgeryders who have done collaboration work, stay tuned!

Call Minutes:

Dorotea: making LOTe4 in real life - festival in Berlin, want to present unMOn, LOTE4 Edgeryders - promoting the event (with Hazem)

Noemi: Agenda: program, stories, session, redesigning the minisite pages before newsletter goes out, twitterstorm, ticket issuing

Ben: CSS rewritten, still not working, so pages are not in good shape - switch over to the page design Alberto set up for hackathon.

Alberto: Yes. Hassle people to write 3-4 proposals, and then other people will be inspired to do it.

Ben: draft skeleton sessions?

Alberto: No need. curators are in place (heavy weighters in policy-making) but they need something to curate.

Ben: people don’t really write up sessions…

Alberto: no need to worry too much

(long explanation, sorry, I got distracted)

Noemi: still makes sense to push people and prompt them to register and start planning their sessions.

• Actionable : Ben to fix Program page and get in touch with potential session leaders

Noemi: Ben, did you get the draft letter template? it is there. Would it be helpful to ask someone in communications to help w. media contacts etc.

Maria: can the case study interview happen on hangout?

Ben: yes. Write-up is on its way. Bit behind on things with Lauren. People suggest other people, hundred project long spreadsheets, etc. Template for an email invite is an easy way to do it (already posted) …

Maria: Thanks, yes cool. Is there anyone in Matera who needs to be interviewed;

Ben: Library guy, Leo, Andrea P., Mimi. Framework for interviews - there is a wiki.

Maria: Saverio?

Ben: yes.

Alberto: audio issue. Microphone?

Ben: good call.

Noemi: who is supposed to prune the list of contacts?

Noemi: Us in Communications. There is another list, Nico and Ben are working on it, list of contacts in Matera. Is that under way?

Maria: Case studies: English, or native language?

Noemi: preferably English. Others need subtitles and time is short.

Alberto: Keep non-English short.

Noemi:Is the list for me or Nico?

Ben: it is the list of people we cannot get to. It is for others to contact.

Noemi: not have been approached?

Ben: Some of them have no been. Will mark those.

• Actionables: Ben to go through list and highlight who and who has not been approached 
• Noemi & Communications to go through the list and send Case Study Interview questions + invitations lo Lote4

Alberto: Twitterstorm?

Noemi: At a minimum, we need 3 sessions and 3 case studies to push out during the event

Alberto: Let’s try to get the Italians on board: also ask Raffaella and Serafino at mt2019. Giovanni Calia too, maybe?

Dorotea: we plan to make Making Lote in RL on the 14th, we might make some fresh meterial for the twitterstorm

• Actionable: @NicoBis to post a call for Twitterstorm on his site, then spread it with his contacts
• Nico to make a 40 sec video trailer for Lote4, using footage we have so far with Matera; no need to have people talking, just music and beautiful frames

Accommotation at unMonastery during Lote:

• Natalia to take this on when she gets in Matera - figure out how many free spots and offer them to participants; clear the schedule with Rita Orlando first -> Ben to send introduction email

 

[ben]

Questions about teams!

Is there a reason why we’re not deploying coordination pages for each team similar to spot the future?

It strikes me that this could be enormously useful for coordinating and having a decent landing spot for people who want to help, thoughts @alberto @noemi @matthias ?

[alberto]

Already there

I have been using the #LOTE4: The Stewardship group to that end. But good idea actually, let me rename it “LOTE4 coordination team”.

[ben]

Misunderstood

The futurespotters page uses a different layout which I thought would be useful as a landing point, since it lists active tasks etc.

But more importantly, I think this layout is really useful for individual teams here: /t/lote4-the-stewardship/359-dashboard - because right now lots of people have signed up to teams but when you click the link it takes you to a single task. If I then go to use the main stewardship group and I’m in a particular team, you’re forced to wade through posts to find the ones that are relevant to you.

Where as if each of the teams on this page /t/lote4-the-stewardship/359-dashboard linked to a coordination page specifically for that area, it’s more likely people can work on tasks, ask questions and take initiative - right now it’s my observation that the only people who are doing a lot of work are those that have experience using Edgeryders and just post where it seems to make sense and ping each other.

@Matthias would it be easy to set things up like this or?

[matthias]

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

1. 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).
2. 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
3. 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.

[alberto]

Even cleaner

I propose not one, but two solutions even cleaner than @Matthias's.

1. Teams as projects. A project is a group of people that move towards a certain goal. That applies to all LOTE4 teams. This solution does not require extending our present data model; plus, each team gets the whole package: posts to communicate internally, wikis, tasks... The Hackathon team already has its own project.
2. Only one big team as a project. Same as 1, except now chance interactions across teams is enhanced as people see the posts, wikis etc. of other teams. This is both good and bad: mostly good if activity is weak (does not feel empty), mostly bad if it is strong (is not overwhelming).

Works?

[matthias]

2 works, just not for our biggest projects (conferences)

Your number 2 is the default case we use now, and it works well for all our small projects, since (as you say), activity is weak there, so further compartmentalizing it would squash it. The only case where the “project is a team” equation has the “mostly bad” side effects is conferences as our biggest projects, as shown by Ben looking for a way to keep collaborators from being overwhelmed by all of the tasks at once.

And I’m looking for something to add to just LOTE-size projects, by admins. Normal-sized projects will still keep the “one big team as a project” mode.

Which leaves us with your number 1, where we would model LOTE4 as a set of multiple projects, one per team. This is what we did with Spot the Future, still a relatively small exercise, but it already led to a mess, with people cross-posting to all the STF related projects indiscriminately, to make sure their content get attention, as the overview about which STF projects are there and which are for which purpose had “left”. At least in part because there was no way to see a list of all current STF related projects in Drupal (at least not in the “New Node” form).

Which brings us to the core of why I think the “one project per team” mode was poor modelling for STF: in computer science (specifically, object oriented programming), the standard rule to model (or “cut”) reality into concepts is “high cohesion and low coupling”. The “one project per team” mode meets the first condition, as a project has high inner cohesion, also if employed for a team. But coupling between “normal” projects is quite low (as it should be between separate entities), while coupling between all STF related (or all LOTE4 related) “team” projects is high, expressed through the confused cross-posting in STF by default, towards the end of it. Compounded by the problem of archiving the content: Could you still name all our STF related projects, so you would know where to find all the STF content again?

I’m not a friend of introducing a new concept like “Team”, but if we want to provide non-overwhelming task lists to LOTE4 collaborators, I still think it’s the way to go. Still open for your proposals / arguments though Plus, “Team” would only be available for LOTE-sized projects.

[alberto]

I stand corrected

Plus, I learned the useful concept of cutting reality into sub-units with high cohesion and low coupling. Thank you Matt!

[alberto]

Actually, no

After giving it some more thinking, I decided to revert to my previous position. Your argument on high coupling, @Matthias, is correct, but I don’t think that teams as subprojects would remove confusion and cross-posting, while still meddling the data model. The only advantage is that it would definitely unclutter the projects page). What I would do:

1. give teams simple names (for example "social media team" is clear, whereas "Spot The Future Making A Living" is not).
2. add a "My projects" tab in the projects page. This would make it simple for people to remember which projects they are already contributing to.
3. manually fix any cross posting or posting in the wrong team – this is very easy and fast under our present data model. 
4. (optional) upon termination, reassign all content of teams to the high-level project (LOTE4). This removes the clutter from the projects page, while not overwhelming people with too many email notifications because the project is over and there is almost no new activity in any of the teams. 

But I will accept either solution proposed by you, of course.

[matthias]

Keeping up with just the “project” content type (so, no teams, as you proposed) has the advantage of avoiding too many e-mail notifications, and the confusion caused by having to understand a new concept … . But it does not fix the cross-posting, which happened because there was no place to post where one could be sure to reach everyone associated with the project, if necessary.

To fix this, there could be a main project group (like “LOTE4”) and several sub-project groups, with the main project name as prefix by convention (like “LOTE4: tech team”). Everyone involved would be member of the main project, and optionally one or more of the sub-projects. This has to be ensured automatically, so one can be sure to not miss people when posting to the main project (avoids the cross-posting). It seems that the og_subgroups module provides this functionality (by propagating membership up to the parent group, but not propagating content). Users would not notice that there is a group hierarchy at all, as the list of projects can still be shown flat (or omit subprojects if we choose to, then showing them only on a parent project’s page like the LOTE4 Dashboard / Teams page).

Will think about it a bit more … input welcome …

[matthias]

Next thought: “notification rooms”

Woa, software analysis for Drupal is hard … I still don’t have the full set of mental patterns to apply to Drupal problems, but I’d like to get this problem solved cleanly. So, after some more thinking, I have the impression that teams, sub-projects, parallel projects with later merging etc. are all sweet, but fail to correctly identify the problem we have in the first place, and thus lead to solutions that are too complex.

The real problem at hand is noise, as @Ben put it. Which means, notification e-mails. You don’t want to get an e-mail about every single comment to every single session proposal just because you intend to visit a conference. For other problems related to clutter, we have always deployed specialized solutions (such as, not including every event into the program but only those that got approved). But for notification noise we did not have one … I think that we can keep up with a strict “one project per project” rule if we solve notification noise like this:

• Option to not send notifications at all when creating a piece of content, with defaults per content type that can be overridden in the content creation sidebar.
• Not sending notifications for comments just because somebody is subscribed to a project, only if somebody is also subscribed to the thread.
• Optional: Allowing to select one or more of different "notification rooms" when subscribing to a project, and assigning different actions to these different rooms. For example: everything related to social media would go to the audience in  a "LOTE4: social media" notification room.

I’ll see how I can implement these …

[matthias]

Problem is the breadcrumb trail (and semantics)

With the renaming, all group content incl. minisite pages will show “LOTE4 Coordination Team” in the top in their breadcrumb trail, even though the group contains the public-facing information in addition to the “internal” coordination work. And, as I argue above about modelling, it should also stay like this: let’s have one Project node per project (and develop sub-structuring means like “Teams” on the go).

And LOTE4 is one project (the Hackathon can be considered its own project, that’s fine). So, I think it’s better that I revert your change to “#LOTE4: The Stewardship”.