Assuming we run on turk, we can do a fair amount of auto payment, and possibly auto qualifications (e.g., #116), but occasionally we need to actually post and remove surveys.
For example, we might want to break down and renew our surveys every day so that most of them stay at the top of the turk heap.
This can be done via cron, and could be set up to be done at the same time as data retrieval (#117), but we should design around this type of automation.
Some things to consider here are if we should use HITTypes or just make new HITs. Another if if we should have some kind of specification of needs for the panel, e.g., we need at least 3000 people with these surveys by 3 weeks from now, that is used to modify any aspect of the automatically generated hits, e.g., price or qualification access etc.
This has a bunch of details to think about so would be interested for thoughts from @JamesPHoughton, @TutiGomoka and @rivera-lanasm.
@rivera-lanasm — the issue of how these HITs should be identified and differentiated might be another thing to think about in the context of the API limitations.
Assuming we run on turk, we can do a fair amount of auto payment, and possibly auto qualifications (e.g., #116), but occasionally we need to actually post and remove surveys.
For example, we might want to break down and renew our surveys every day so that most of them stay at the top of the turk heap.
This can be done via cron, and could be set up to be done at the same time as data retrieval (#117), but we should design around this type of automation.
Some things to consider here are if we should use HITTypes or just make new HITs. Another if if we should have some kind of specification of needs for the panel, e.g., we need at least 3000 people with these surveys by 3 weeks from now, that is used to modify any aspect of the automatically generated hits, e.g., price or qualification access etc.
This has a bunch of details to think about so would be interested for thoughts from @JamesPHoughton, @TutiGomoka and @rivera-lanasm.
@rivera-lanasm — the issue of how these HITs should be identified and differentiated might be another thing to think about in the context of the API limitations.