when creating projects, votes and ECC should influence player assignment

[tannerwelsh]

Use a simplified version of the original "project creation" algorithm: https://github.com/LearnersGuild/learning-os/blob/master/game/processes/project-creation.md

Constraints:

• Team leads can only lead projects from the same goal
• No project can exist without a more experienced team lead
• No team should be without a Lead
• Team Members can only be on one project
• Each Team Member's experience and skill level should be approximately equal

[heyheyjp]

Other follow-up thoughts:

• Part of what makes it hard to work out handling for situations like the one above is that there's little we can assume ahead of time about the recommended team sizes for goal projects. What if instead of scaling the size of the team to the scope of a nominated goal, we forced the scope of the goal to a specific team size (and the cycle duration)?
• What if team leads were not counted/considered in the recommended team size? We've already established that it's essential that leads be able to work across multiple teams. What if we removed them altogether from team formation? They'd be expected to "float" amongst as many teams in the goal group as necessary. This is the model that's been encouraged for enrollment games (instead of attempting to pair with people individually, remain a "floater", able to more closely observe and work with people across teams at all times). Leads are given feedback by the people in the teams they worked with just the same. And this would reduce the complexity of the algorithm. Thoughts on that?

[jeffreywescott]

What if instead of scaling the size of the team to the scope of a nominated goal, we forced the scope of the goal to a specific team size (and the cycle duration)?

It may be the case that for the first version, we could do this, but I'm not sure. In fact, I think part of the hope was that the first few weeks there would be a lot of "pairing" before folks "graduated" to larger-group work. But I think it might be too constraining (at least for the first 10 weeks) to fix the team size completely. We already have said that (for v0), the number of cycles per project is 1, but even that will change longer-term. I'm reluctant to paint ourselves too much into a corner here.

They'd be expected to "float" amongst as many teams in the goal group as necessary.

My (admittedly, limited) understanding of "cognitive apprenticeship" is that people are "working together". So the team lead should be actually pairing rather than just answering questions. It seems that this "floating" thing is already baked-in to the algorithm because we are optimizing to assign team leads to goals that they're already working on.

I was concerned about this as a "hard constraint", too. I think @tannerwelsh's original algorithm had it as an optimization rather than a constraint. I think I'd recommend we go that route, too. For example, add another constraint (perhaps just for the first 10 weeks) where "team lead responsibilities should be roughly balanced" even if it means that a team lead may be working across different goals. @shereefb / @tannerwelsh?

[heyheyjp]

But I think it might be too constraining (at least for the first 10 weeks) to fix the team size completely.

Ok. Though an argument could be made that this is what developing software in real life is like, anyway. More often than not, you have a fixed number of people and have to adjust project duration and/or scope to fit that constraint. :)

[jeffreywescott]

you have a fixed number of people and have to adjust project duration and/or scope to fit that constraint

That's a totally fair point. But we cannot lose sight of the fact that, in this case, the Learners are creating their own goals that are "stretchy" for them rather than having the specs / requirements handed to them from a cross-functional team (file-under: self-directed learning is more fruitful). I think Player Support should definitely offer a lot of coaching as to how to make goals "stretchy" but still fit within 1 cycle, but I don't think it's a good idea to make the software depend on a certain team size. My hunch is that this is one place that we really do need to accommodate some (constrained) variance, e.g., team sizes will always be between 2 and 6 (or something).

[jeffreywescott]

To be really specific, I imagine that we're going to want the learners to do a lot of pairing in weeks 1-4, then move onto more group work from weeks 5-10. I might be wrong about this, but IIRC, that was something we were aiming to accommodate in the v0 algorithm.

[heyheyjp]

OK, that's good to know.

[heyheyjp]

@jeffreywescott: still holding a tension then about including team lead in recommended team size. If we expect mostly team-size-2 goals in the first few weeks...and leads can be expected to work across multiple projects...folks would be left working alone while their pair, the lead, is engaged elsewhere.

[tannerwelsh]

So the team lead should be actually pairing rather than just answering questions.

Yup, team leads need to be contributing for CA to work.

As a mechanic, I'm ok with the scenario of "one team lead gets assigned to 3x 4-person teams, and another to 1x 2-person team". What will likely happen is learners will take this into account when voting (i.e. super-popular votes will become less attractive because of the reduced contact w/ team lead).

What if instead of scaling the size of the team to the scope of a nominated goal, we forced the scope of the goal to a specific team size (and the cycle duration)?

Unfortunately I don't think we can bend on the variable-team-size. We could put in some upper- and lower-bounds (i.e. 2-7), but forcing projects to fit w/in a particular team size is going to be tough.

For the first phase, I expect we'll have more team-size-3 goals (i.e. pair + 1 lead). After that, probably a healthy mix of sizes 3-6.

[tannerwelsh]

If we expect a lot of team-size-2 goals and leads can be expected to work across multiple projects...folks would be left working alone while their pair, the lead, is engaged elsewhere

For now, what if we enforced a constraint of team size ranges between 3 and 7? I.e. no fewer than 2 members + 1 lead, no more than 6 members + 1 lead.

[heyheyjp]

@tannerwelsh: I suppose I'm just unclear as to why it's necessary to count the lead against recommended team size at all? Instead of making repeated checks of does team size (w/o a lead) = rec team size - 1? we could simply check for does team size (w/o a lead) = rec team size.

[tannerwelsh]

@prattsj it is an annoyance, but I think it's important that the visible rec team size is a number that includes the team lead. When creating goals, learners should be thinking of team sizes as including the lead.

If, when storing goals in our system, it makes more sense to exclude the team lead, that's fine. The adapter between goal issue labels and game can increment/decrement as needed. I just don't want to introduce a UI to learners that excludes leads from the team size.

All part of our campaign to slowly erode the notion of the "teacher" being separate from the "group". All in the same boat, just with mixed experience.

[tannerwelsh]

Sharing some thoughts that influence how I think about ~team lead~, ahem, advanced learner assignment. No action necessary here, just leaving this as a nugget for future reference if needed.

There are (at least) three dimensions to consider when assigning team leads to ensure that (a) team leads are not overburdened and (b) effective cognitive apprenticeship can take place:

1. context consistency (assumption: requires less cognitive load to work on multiple projects that share same goal)
2. size of relationship graph (assumption: more members = more people lead has to track and get to know. also, each additional member in a team grows the total number of relationships between members factorially, so it requires more social/emotional effort to oversee large groups)
3. expertise differential (assumption: more skilled leads will be able to manage more complex tasks)

Which of these dimensions to optimize for is a difficult question to answer. I don't think we know enough to say accurately. So we should design to run the least-risky and most backwards-compatible experiment possible.