Add "Internal Name" to researcher study views
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 12
- Forks
- 21
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 5
Description
TL;DR
Researchers do things with the name of the study that we don't expect and don't make sense from family perspective, like calling something "What is My Favorite Animal Version 2?" Here are some real examples from the db:
"2Copy of [Template] Minimal Lookit video consent redirecting to an external study"
"Researcher name - Copy of Thesis"
"XYZ Pilot (updated through v12)"
Instead, we can break up the family-facing name and a researcher-facing label, a new study field called "version-name-internal" (following our var naming conventions of course.) This should hopefully lead to less study-splitting/unnecessary cloning, better naming for families, and better tracking/versioning for researchers.
Stretch goal: Inject this internal name/version info into the study response table, creating a manual versioning system that researchers can use!
Narrative
As a researcher, I want to run 20 studies that are all very similar to one another, and in most cases I don't want repeat participants to appear across these studies. Right now, the most common workflow is:
(1) Make a clone of existing study. Give it a slightly confusing name like "What is My Favorite Animal Version 2?"
(2) Make the necessary changes
(3) Submit for review, and Mark tells you that you need to include the previous version(s) in the must-not-have-taken criteria
(4) Resubmit.
(5) Repeat 20x, resulting in 20 live studies with similar names
A better workflow would be:
(0) Optional: Make a clone of the existing study, as a backup to preserve the old version. In the researcher title/version field, describe what it was/is "e.g. Version 1, November 2023-Jan 2024". (Note - this allows study rollback without us having to introduce and maintain real versioning!)
(1) Make updates to existing study, and rename the researcher field, e.g.:
Family facing name (Current study title field): What is this animal?
Researcher name: "Version 2, starting Feb 2024"
(2) Submit for review as a minor update, hopefully sail through without issue.
Acceptance Criteria
- Field exists in database
- Check all researcher facing views to make sure that both titles appear where they should
- Check study creation/update forms to make sure that the new field is well explained, and the old one differentiated in the helptext
- Make sure that version-name-internal appears on study responses, because this will help researchers version their studies!
- Update study creation documentation page with new fields
- Create docs page on running multiple study variations in the intended pattern!
Implementation Notes
Make sure that the two titles get displayed together in a way that makes sense, e.g.
What Animal Is This?
Version Name: Version 2, starting Feb 2024
Text for study creation form:
Study Name
[ ________________ ]
The name of the study that will be shown to families for email invitations and study pages, e.g. "What Animal Is This?"
Version Name (Internal)
[ ________________ ]
This part is not shown to families, but it will be included in your individual response data and shown on researcher-facing pages. You can use it for an alternate name for your study and/or to keep track of study versions and changes. See [this page](link to docs) for more detail on running multiple versions of the same study.
Lab
[Dropdown]
(etc)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the study model and the researcher-facing views and creation/update forms, then trace how study responses are represented. Check each acceptance criterion across the database, forms, views, response data, and documentation. Done means both names are explained and shown appropriately, the internal name appears in responses, and both requested documentation pages are updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design, databases, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100