lookit / lookit/lookit-api

Support for participant compensation - point system

Open
#137 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Discussion Feature Participant Researcher Scoping Staff
Dominant language
Python
Stars
12
Forks
21
Avg merge
5d 19h
Merged PRs (30d)
5

Description

*Pain point*: Compensating participants is necessary both for treating their time/effort fairly and for rapid recruitment. Currently labs are individually responsible for identifying participants who should receive compensation and sending gift card codes by email through the experimenter interface, which is time-consuming and introduces unnecessary possibility of human error. Setting up to give "points" per study, which families can collect across studies/children and flexibly redeem, would give us a variety of ways to improve recruitment & user engagement.

*Acceptance criteria*:
* Participants can see how many points are associated with completing a particular study, and any restrictions (e.g. how many sessions per child are eligible for compensation, usually one).
* Participants can see how many points they have received for their past study sessions, including whether status is still pending.
* Participants can see their total number of points and "shop" with these from a selection of potential rewards. Participants can see past "orders" or are notified by email when points are exchanged.
* An admin can manage the available rewards (e.g., gift cards, children's gear/toys/books, donations to charity): for each, a description/picture, number available, number of points each.
* An admin can see or is notified of participant selections of rewards, and can mark them as fulfilled.
* Researchers can set the point value of a study and allocate points to sessions. Similar to consent coding, a researcher should be able to say whether to provide compensation for a given session and that determination + the researcher's identity should be stored with session data. Researchers should be able to easily see for which sessions children met eligibility criteria, and should be able to group sessions by child and by user (family).
* An admin can see how many points have been allocated by a given researcher/organization, and mark some number of those as paid, with a record kept of such adjustments, since researchers will be asked to cover their own participant compensation costs.
* A researcher can see how many points they/their organization has allocated total, and how many are unpaid, with a record of transactions.
* Nice to have: an admin should be able to allocate additional points on any study, to allow Lookit itself to create incentives separate from researchers'.
* Nice to have: researchers can specify a maximum number of sessions to allow as part of their study definition, with the study automatically deactivated after reaching that threshold, to avoid unknown costs.

*Implementation notes/Suggestions*: Allocation of points could be done in a GUI analogous to that for consent coding, or actually in the same interface (although storing consent information should be possible without also determining point allocation), and/or by uploading a file. Note that tracking points allocated by organizations could also be done by having them "pre-pay" for some amount of points and only be allowed to "spend" up to that amount, as on MTurk; due to MIT's billing practices we will likely prefer just to let them allocate whatever points they want (clearly indicating the total) and bill them later.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Use the acceptance criteria as the requirements, starting with the experimenter interface and the existing consent-coding workflow mentioned in the implementation notes. Done requires participant point balances and rewards, researcher and admin allocation views, fulfillment and payment records, and eligibility restrictions across studies and sessions.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, payments
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.