Improve child registration and demographic surveys
- Dominant language
- Python
- Stars
- 12
- Forks
- 21
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 5
Description
**TL;DR**: Review and revamp the child and demographic surveys after considering what information is most important to collect as well as family experience.
**Child characteristic options**: Right now we have a small set of checkboxes for various characteristics that parents can select from when registering a child - ASD, multiple birth, deaf, hard of hearing, dyslexic. It would be useful to have a more comprehensive set of options, but when we started listing conditions/characteristics off the tops of our heads we realized we don't have a good idea of the relative frequencies of various conditions -- or their relative frequencies in specialized research - to put together an appropriate set of options (that won't leave parents wondering why e.g. Down Syndrome is there but another trisomy isn't). This would be a great project for someone new to Lookit to take on - figure out a principled way to build a list, survey experimenters and/or families, etc., and propose an extension.
**Demographic survey questions/options**:
Collecting detailed demographic information is important for working towards a representative sample, and understanding in what ways our current sample is non-representative.
You can see the current survey at https://lookit.mit.edu/account/demographics/ if you make an account.
The current family demographic survey is somewhat haphazard - it definitely provides useful information, but no individual question has been considered as carefully as it would ideally be (and there may be questions left off). E.g.,
* Family income: should we really be querying annual income in USD in increments of 10K up to 200K? What bins would be most appropriate? Do families generally interpret the question in a consistent same way or do we need to clarify the wording?
* Could we switch to a gender question that isn't literally "other"-ing both on the demographic survey and for children? What is best practice there - offering a custom write-in, just offering non-binary?
* Would it make sense to ask for the gender of the surveyed parent's spouse? On one hand it'd be helpful for e.g. being able to extract "maternal education level" (currently we could use "education level of female parent / education level of male parent's spouse" as a rough approximation). On the other we have less direct use for this information, and which families have same-sex parents might be unnecessarily sensitive information (or families might be concerned that it will get used for e.g. comparing "how the kids turn out" without permission).
* UI: how should we have families enter languages & birthdates?
* Race categories: can someone look into best practices here? I took them from the census; it's definitely an improvement over free-response (which was a lot of coding, and often ambiguous - e.g. people entered their religion or nationality, or said "Hispanic" which didn't allow direct comparison with the US census). These are admittedly US-centric but so is our recruiting for now.
* What other info should we be collecting? I can think of a bunch of things that'd be interesting but ideally we'd (a) keep the form reasonably short and (b) collect information we can compare with available large datasets or research. Age at first child? Involvement of grandparents? Food insecurity?
Another great project for someone to take on and come back with recommendations.
Contributor guide
Research direction
Start by reviewing the current family demographic survey at https://lookit.mit.edu/account/demographics/ and the issue's questions about child characteristics, income, gender, languages, birthdates, race, and other measures. Research relevant best practices and consult experimenters or families as appropriate. Done means a principled set of recommendations for survey questions and options, including how to keep the form useful and reasonably short.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100