You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our platform is functionally ready for anyone to post work. We will continue to improve its design, interaction, and functionality, of course. We have many workers who have expressed interest, and much of our effort to take has focused on improving the workers' experience: collective rejection of bad tasks, better communication, revision instead of rejection, and so on.
However, we do not yet have a steady stream of new requesters. Daemo will fail without that.
Proposal
It is time we focused on recruiting requesters, so that there is regular, high-quality, well-paid work for the workers.
This proposal affirms a strategic focus on recruiting requesters for the next few months. We cannot sit and wait for requesters to arrive. Consensus on this proposal identifies the area as a strategic priority and over the course of this period, a series of directions could be tried and tested.
So, how do we bootstrap requesters?
For those with lots of data like ML researchers or data science folks, as we know there are many of this type of requester in our networks, the following are a few initial ideas:
Consider adding workers from universities we have access to with specific expertise needed for such projects: for example, people with undergrad stats training, to support @mbernst's earlier task on extracting statistical tests from AMT. They may demand more pay, but we have a very ready supply of talented undergrads at Stanford who will do things for money (they do psych studies already, so I'd bet they'd do Daemo stuff if the tasks are sufficiently lucrative)
To be clear, we don't have to do either of these --- just brainstorming.
We might also consider some more general strategies such as:
Make clear the more ethical treatment of workers
Consider bringing in more workers, enough to support some social science experiments --- might require navigating expectation around fluctuations in workload
Make it easy for requesters to republish to AMT in the worst case --- e.g., allow our tasks to be cross-posted as ExternalQuestion iframes on AMT --- so they have little to lose.
Targeted marketing to communities who may make use of Daemo through online advertising campaigns.
Again, more brainstorms than concrete decisions.
With all of these, a valuable consideration is also how we measure improvement around this issue. Although this strategy proposal does not intend to explicitly suggest a measure, this is another aspect which could be addressed in supporting proposals.
Implications
Short-term: this proposal may involve shifting some focus from feature development to support and getting the word out.
Long-term: this will be the important test we must pass --- are the ideas behind Daemo sufficiently good that we can attract usage? If not, the platform needs serious reconsideration. If so, it will prompt additional needs (e.g., more workers, bugfixes, iterations on the UI).
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.
The text was updated successfully, but these errors were encountered:
This proposal seems very confusing to me. The title talks about adding requesters but most of strategies seem to be focused on workers (there is only one thread I can think of which seems related in this way if we are trying to screen requesters based on skill-sets of workers on the platform)
Ideally to focus on adding requesters, we need documents clearly defining what are the ways to
screen requesters apt for the platform based on domain, avg. length of tasks they might push, avg. value addition per task, skill-sets in demand match with workers, geography being targeted etc.
induct the requesters based on number of workers on platform and min. time we can guarantee for their tasks to get completed
orientation on how to best make use of the platform quickly, how they can best reach out to the teams, workers or engage collective if they are looking solution for a problem.
Problem
Our platform is functionally ready for anyone to post work. We will continue to improve its design, interaction, and functionality, of course. We have many workers who have expressed interest, and much of our effort to take has focused on improving the workers' experience: collective rejection of bad tasks, better communication, revision instead of rejection, and so on.
However, we do not yet have a steady stream of new requesters. Daemo will fail without that.
Proposal
It is time we focused on recruiting requesters, so that there is regular, high-quality, well-paid work for the workers.
This proposal affirms a strategic focus on recruiting requesters for the next few months. We cannot sit and wait for requesters to arrive. Consensus on this proposal identifies the area as a strategic priority and over the course of this period, a series of directions could be tried and tested.
So, how do we bootstrap requesters?
For those with lots of data like ML researchers or data science folks, as we know there are many of this type of requester in our networks, the following are a few initial ideas:
To be clear, we don't have to do either of these --- just brainstorming.
We might also consider some more general strategies such as:
Again, more brainstorms than concrete decisions.
With all of these, a valuable consideration is also how we measure improvement around this issue. Although this strategy proposal does not intend to explicitly suggest a measure, this is another aspect which could be addressed in supporting proposals.
Implications
Short-term: this proposal may involve shifting some focus from feature development to support and getting the word out.
Long-term: this will be the important test we must pass --- are the ideas behind Daemo sufficiently good that we can attract usage? If not, the platform needs serious reconsideration. If so, it will prompt additional needs (e.g., more workers, bugfixes, iterations on the UI).
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.
The text was updated successfully, but these errors were encountered: