What should we expect out of the first Users consultation?

[manuGil]

• What to expect in terms of which use-cases? Which use-cases have a priority?
• What to expect out of consulting users/community about such use cases?

[manuGil]

1. We will do the first ranking among the project dev team? and send it via email (on Wednesday 30th March) We will decide what to do further after looking into the results.

[jurra]

I would also add to specify the target audience and the context. For example:

Given that there are computational environments that researchers access remotely, being jupyter hub + jupyter lab one of the most prominent ones.

We believe that such environments can benefit from simple interfaces to deposit data in archiving repositories. Therefore we plan explore the implementation of such interfaces to simplify current manual procedures.

How can we get help to learn more about this?

• Those who know researchers in this situation (data stewards) can help us verify that this is a current or potential issue among their research community.
• They can also help us find out advanced users that use jupyterhub as part of their research infrastructure.
• Those users who already encounter this difficulties (actual researchers with experience in open science, publishin and archiving)

[heijer]

I Think it is very important to make sure to build something feasible that has the core functionality. Especially in the early stages, the tool will be only interesting and useful for advanced users. When it proves to be successful, the threshold can be lowered by making it more user-friendly to also attract less advanced users.

Core functionality should stay as close as possible to standards and protocols to prevent as much as possible that initial implementations have to change drastically and thus effectively need to be re-implemented.

Based on this, I would prioritise the following user stories:

• I want to store metadata locally so that I can create and update it easily.
• I want to edit metadata with my favorite text editor/IDE so that I can create and update it easily.
• I want to archive a dataset directly from my working environment so that I can perform the task without using a web-based GUI provided by the data repository.

For these user stories, a metadata standard needs to be selected (suggestion: Dublin Core) as well as a protocol (suggestion: SWORD). By providing an environment/CLI around that, an advanced user should be able to start using it.
Many of the other user stories are in practice very tailored to particular file formats and types of data (e.g. extraction of metadata from data files and keeping documentation and metadata in sync). In addition, an advanced user will be able to do that himself and is probably already doing that now.

When the CLI does support the core functionality and proves to work, next step could be adding the JupyterLab GUI. So, the next user story would be:

• I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment.

[manuGil]

I went thru the project proposal to find what deliverables (thinks we promised) are relevant to the user's stories. There were very few of them (which is good because we don't have many restrictions.

NWO Proposal Deliverables:

JupyterFAIR - will be developed to allow researchers:

1. take a ‘snapshot’ of their research data (version/release, in a computational environment).
2. auto-generate metadata.
3. publish (data and metadata) to the data repository quickly and easily.
4. complete the above tasks via a 'one-click' tool from a research environment (a.k.a. JupyterLab).

User's stories vs NWO Deliverables

This is my take on how the user's stories related with the list above.

[1]

a. I want to specify which data files and folders are included in the dataset so that I can manage the dataset easily.
b. I want to archive a new version of the dataset with minimum effort so that I can archive not only the final version, but also important intermediate ones.
Considering the above as a starting point to decide what user's stories to prioritize. I compile the following list.

[2]

c. I want to import metadata available in the documentation (e.g. README file) so that I don't need to manually enter the same information.
d. I want to import metadata available in the data files so that I don't need to enter the information manually.

[3]

e. I want to archive different datasets from the same project environment so that I can publish data from different parts of the study.
f. I want to archive large datasets without upload or connectivity issues so that I can publish my research outputs completely.

[4]

g. I want to archive a dataset directly from my working environment so that I can perform the task without using a web-based GUI provided by the data repository.
h. I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment.

Priorities

The list above is too ambitious for the few months that we have for development. Therefore, I think we should prioritise the following:

1. I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment. (This is very close to the third item in Kess' list)
2. I want to import metadata available in the documentation (e.g. README file) so that I don't need to manually enter the same information. (In line with the first and second items in Kees' list, although the how might be different).
3. I want to specify which data files and folders are included in the dataset so that I can manage the dataset easily.

[girgink]

Hi all,

Sorry for the late feedback. My list of priorities is as follows:

• I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment.
• I want to edit metadata with my favorite text editor/IDE so that I can create and update it easily.
• I want to update the local metadata record with the remote version available on the data repository so that they are synchronized.

The first one is partly biased as it is the overall aim of the project proposal. But surely it is a nice feature and superseeds " want to archive a dataset directly from my working environment ..." story. Also I have the feeling that these two stories are umbrella stories, which cover some others. For example, it is not possible to archive a dataset without selecting files and entering even basic metadata, so it is almost certain that related user stories should be realized already (e.g. local metadata, etc.),

[jurra]

Hello everyone,

Here is my list of priorities:
• I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment.
• I want to archive a dataset directly from my working environment so that I can perform the task without using a web-based GUI provided by the data repository.
• I want to archive a dataset directly from my JupyterLab GUI so that I can perform the task without leaving my working environment.
• I want to specify which data files and folders are included in the dataset so that I can manage the dataset easily.

Rationale

This is part of one big story focused on one single task, to deposit data in the repository. I see it as an increment that is sound and complete.