How might we administer the task sharing aspect of this design?

[markwhiting]

At a high level, we would like to run an ecologically valid field experiment to measure how people respond to costs when deciding to embark on altruistic behavior. The concept of the experiment is to allow Turk workers to choose to share a task with others in at least two conditions:

• a task with limited availability, so sharing it incurs an opportunity cost (tasks recipients complete are not doable by the sharer),
• a task with unlimited availability, so sharing it incurs no cost to the sharer.

We would then measure how differently people share depending on this condition. We could additionally parameterize these conditions to include dimensions like the cost, if the cost is punitive or opportunistic, and if properties of the task entail different sharing behavior. Other extensions would be how kickbacks balance this behavior, e.g., how pursuit of community reputation relates to the cost of the altruistic behavior.

With our infrastructure and the constraints of the Turk platform a few approaches to this experiment are possible:

Share publicly

In this design, workers could choose to share a link on a public or private forum. The link would allow any worker who saw it to join our experiment. This would be implemented by creating an opt in cycle that would qualify a specific worker, upon completion, to see and complete the HITs in question. Of course, we could track which link people clicked on (who's altruism they benefited from) and create a ecologically sound world wherein completion of that specific person's invites only costs them, not others in the experiment.

A weakness of this design is that competing public links will mean that people will need to make choices about whose link to click on on public forums, confounding our ability to precisely measure the impact of one workers altruistic behavior.

Email workers

In this design, workers would specify an other workers to share with by email address. We would then email those workers with a one time use link that would put them in the qualification cycle as above.

This has the advantage that we would reduce the spillovers of multiple links being shared in a community, but it has the disadvantage that it requires people to know the emails of other workers. My suspicion is that this is known but that it signals a stronger social tie, which might serve as a different confound. It also has the challenge that we need to integrate with an email system.

Indicate workers WorkerIds

In this design, workers could write in WorkerIds, or choose from a list, e.g., the list of all people already in the panel.

This has the advantage that it requires the least integration, but an even stronger form of the Email workers disadvantage. Most workers probably don't know others WorkerIds and if they do, they're probably good friends.

Let us choose with whom to share

In this design, perhaps as an alternative to some of those above, a worker opts to let us share the task with a certain number of other workers. They could even choose that number if we like. We would then engage those workers directly via our panel.

This has the advantage that it is the most easy for us to execute, but the disadvantage that it removes any specific social component. Another view of that is that it shifts the social context from known individuals to people in a similar situation (other Turk Workers), which may have some interesting implications too.

[markwhiting]

@duncanjwatts — can you add any thoughts to this.