I am planning an experiment in which participants interact in a chain: One participant starts and finishes the task, then another participant joins and does the task (accessing some data from the previous player). And similarly, when this participant finishes, another participant joins and does the same for a number of players. Let's say 3 for simplicity.

This is going to be an online experiment in a crowdsourcing platform, and I am not sure how to implement it best.

Now, in order to structure the experiment in a group, I should start these three people as a group. In this case, each participant should wait their turn to play. This works, but obviously, this is not ideal due to long and unnecessary waiting times.

The second way is to run each "generation" as a separate session: Get the data of the first players, then plug it into the second session. Then get this data for the third session. This seems doable, but given that it needs a lot of manual work (potentially can be automatized at a degree but still...) and is prone to errors, I am not sure if its the best way.

Now the third option would be ideal in my mind, but I am not sure if it's possible. The first participant enters, plays, and finishes the task. And then, the next participant entering the session will be the second player in that group. So is it possible to add a participant to an ongoing group? Or keep a bot until the player arrives. 

If you have any ideas on the implementation of this third option or some workarounds and tips related to the second or the third option, I'll be really grateful.

See 'intergenerational' here: https://www.otreehub.com/projects/?featured=1

Thank you very much, Chris. The code certainly is very helpful. Let me ask a question, meanwhile also explain the suggested app, so it would be helpful for future reference. 

As far as I can see here, the session itself is an intergenerational experiment with a single group (chain). There are no groups (i guess because the groups, by definition, consist of non-independent players and the players in the group cannot start at different times). So the trick here is 

 - each person is in its own group alone (aka PLAYERS_PER_GROUP = None)
 - a session variable keeps the chain-level information. (Hereby a single list, `intergenerational_history`). 
 - And group_by_arrival_time manages the traffic: whenever the active player is done, it takes the next person waiting. Otherwise, locks the grouping for the chain. It unlocks when the player is finished

Of course, it's a huge improvement compared to everyone having to wait for everyone to connect. But as far as I understood, if I need multiple chains, let's say I need 3 chains with 4 players each; I cannot have it with the current code. 

Given this model, I am guessing that what I should try to modify in this way:

- Have a more complex session-level variable containing each group's relevant data (like a list of dictionaries, or dictionary of dictionaries etc)

- Have a more sophisticated `group_by_arrival_time_method` that kinda does:

    - If there is a chain that is not locked (aka the last active player in the group is finished), create a new (single-person) group with the waiting player and associate the player with the relevant chain.
    
    - Else If there are no available groups and if number of current chains < number of desired chains, create a brand new chain
    - Else, wait until the next group is unlocked. 
    
Does it make sense to you? 

Best,
Ali