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

Created date for published versions is updated to the date of publishing #2075

Open
kabilar opened this issue Nov 14, 2024 · 2 comments
Open
Assignees
Labels
UX Affects usability of the system

Comments

@kabilar
Copy link
Member

kabilar commented Nov 14, 2024

Description

When a Dandiset has published versions the Created date on the DLP for a published version is updated to the date that the published version was created. For example, see Dandiset 000130 which is shown below.

Draft version
image

Published version - January 12, 2022
image

Expected behavior

I would expect that the Created date should be the same for all published versions and the Draft version.

@waxlamp
Copy link
Member

waxlamp commented Nov 18, 2024

I would expect that the Created date should be the same for all published versions and the Draft version

Could you say more about why this is your expectation? I'll break this down into parts so I can ask some more focused questions. First, why would you expect the created date for "all published versions" to be the same? A published version is only created upon publishing the Dandiset, which means each published version should feature a created date matching the date it was published (e.g., the date that appears in the published version number).

Second, why would you expect the draft version's created date to change at all? Actually, I may know the answer to this one: are you thinking of the draft version of the Dandiset as something that becomes the published version, leading to the creation of a new draft version to work on? Our model differs from that: we consider the draft version to be a sort of permanent companion to the Dandiset; it is created when the Dandiset is created, and published versions are created independently "from" it. Under this model, the draft version is indeed created only once, then lives a long life spawning published versions, but never undergoing the sort of change that would necessitate new draft versions being created.

My other broad question is: what problems did this mismatch in expectations cause for you specifically? I want to figure that out because changing the model will have subtle effects that may cause bugs. We may be leaking implementation details into the interface in a way that is not helpful, but in that case, I'd want to explore alternative ways of displaying this date data in the DLP.

@waxlamp waxlamp self-assigned this Nov 18, 2024
@yarikoptic
Copy link
Member

yarikoptic commented Nov 18, 2024

I would expect that the Created date should be the same for all published versions and the Draft version.

me too. Whether published or draft, Created here should IMHO correspond to the time point of creation of the dandiset as a whole.

Moreover, as "published" version is published once and should never change, having both "Created" and "Modified" to correspond to the same date gives 0 extra bytes of information and thus questions rationale of having it there. While presenting the date when dandiset was created is exposing the life cycle of the dandiset (created X months ago, this version published Y months after).

The correct date is already present in the metadata which is associated with that dandiset:

❯ curl --silent -X 'GET' 'https://api.dandiarchive.org/api/dandisets/000130/versions/0.241017.1448/' -H 'accept: application/json' | jq .dateCreated
"2021-08-21T19:29:11.649012+00:00"

hence the fact that DLP uses some other date (when the "model" for that release was created... not really corresponding in semantics to "when dandiset was created") is just adding confusion to the user would would be finding correct date in the metadata.

Hence I think this is indeed a UX shortcoming and should be addressed.

@yarikoptic yarikoptic added the UX Affects usability of the system label Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UX Affects usability of the system
Projects
None yet
Development

No branches or pull requests

3 participants