Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Internal Name" to researcher study views #1462

Open
6 tasks
mekline opened this issue Oct 7, 2024 · 0 comments
Open
6 tasks

Add "Internal Name" to researcher study views #1462

mekline opened this issue Oct 7, 2024 · 0 comments

Comments

@mekline
Copy link
Contributor

mekline commented Oct 7, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant