Investigate support necessary for large requesters, and enable it if feasible

[mbernst]

Problem

Right now, there exist technical and institutional barriers to recruiting requesters who have a large volume of tasks. One of the most straightforward ways to increase the volume on Daemo is to find a couple of large requesters. However, enterprises and universities have processes required to get clearance to use Daemo. (They had to do this internally to normalize the use of AMT originally.) Until we clear some of these barriers, they won't be able to use us even if we're publicly launched.

Proposal

This proposal affirms a commitment to engaging with these large requesters (e.g., universities, enterprises) to understand their needs, and designing/implementing what is feasible to support them. We will obviously have to make these decisions collectively on an ongoing basis: some may be feasible, but (for example) it may be impossible to make certain changes without an official organization underneath Daemo, or to implement certain changes without making extremely unwieldy code changes that we are not ready for.

So, concretely, this proposal suggests that we make a good-faith effort to support these requesters, within the realm of feasibility. The requester communication operational group will lead communication with these requesters, and make proposals based on their understanding of what would be necessary to enable that requester to join the platform. Possible proposals that may come up in the course of this strategy:

• Payment through purchase order, i.e., invoice + ACH Credit Transfer
• Mechanisms to keep data private, e.g., a requirement that workers sign an NDA or IRB before doing any tasks for this requester; possibly, a federated version of Daemo that hosts the tasks and data on their own server internally but lists the tasks at daemo.org
• Communication with Stanford's legal team to ensure that we remain compliant as a research project
• Clearer explanation of Daemo's TOS/privacy policy

Implications

Short-term implications most likely include communication with these large requesters as they reach out to us, and possibly some engineering efforts if we decide to pursue.

Long-term implication: this is absolutely required in order to achieve the same reach as, for example, Mechanical Turk. Given that we have interest from some of these groups now, I think it would help us bootstrap and achieve our long-term goal of many requesters and workers on the system.

Contact

@michael Bernstein on Slack

---

To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.