Help Wanted: stories related to "Submit for Review" and "Return to Author"

[Philip Durbin]

If you are unfamiliar with the "Submit for Review" and "Return to Author" feature of dataverse, here's a description from http://guides.dataverse.org/en/4.7/user/dataset-management.html#submit-for-review

---

If you have a Contributor role (can edit metadata, upload files, and edit files, edit Terms, Guestbook, and Submit datasets for review) in a Dataverse you can submit your dataset for review when you have finished uploading your files and filling in all of the relevant metadata fields. To Submit for Review, go to your dataset and click on the “Submit for Review” button, which is located next to the “Edit” button on the upper-right. Once Submitted for Review: the Admin or Curator for this Dataverse will be notified to review this dataset before they decide to either “Publish” the dataset or “Return to Author”. If the dataset is published the contributor will be notified that it is now published. If the dataset is returned to the author, the contributor of this dataset will be notified that they need to make modifications before it can be submitted for review again.

---

I'm interested in your hopes and dreams for this feature.

I have stories already from Amber Leahey from Scholars Portal and Steve McEachern from Australian Data Archive (thank you to both!, but I want more. MORE! I'll even take more stories from Steve and Amber.

The reason I'm asking is that on Monday I started hacking away at the "backend" of this feature (database stuff) and I want to build the backend well enough that we can build a nice GUI on top some day.

Reading through all of https://github.com/IQSS/dataverse/issues/3943 is highly encouraged but not required. Comments on that issue are very welcome!

Please let me know your hope and dreams! Replying here rather than commenting on the GitHub issue is perfectly fine.

Thanks,

Phil

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

[Philipp at UiT]

Hi Phil

Enhancing the review workflow is highly appreciated. As for the GUI, in addition to the message feature for communicating requirements to the author, it would also be useful to add "Returned to Author" as a Publication Status. As for now, the only status tag for a returned dataset is "Unpublished", which doesn't really tell the curator or the author whether the dataset has been reviewed and returned or not.

Best,

Philipp

[Philipp at UiT]

Actually, there are some more features which would make the curator's job easier

1. Include the version number in the submitting message, i.e. when a dataset is submitted for review, the message to the curator should state whether this is an entirely new dataset, or a new version of an existing dataset.

2. Include the scientific subject of the dataset (e.g. Mathematical Sciences) in the subject field of the message that is sent to the curator when the dataset is sent for review. At our institution, curation is carried out by a pool of subject librarians. Including the scientific subject in the subject field of the message would make it more efficient to assign the dataset to the right curator/subject librarian.

Best,

Philipp

[Philip Durbin]

Thanks, Philipp! These are exactly the sorts of ideas I'm looking for. You seem to be describing several problems or deficiencies. Let me attempt to address them one by one in the form of a "UX observation" like we heard[1] about at the community meeting.

My first observation is that you like the "Publication Status" label and that the author can't easily tell that a dataset has been returned. (Obviously, the notification is not enough.) To solve this problem, you're suggesting we add a new label called "Returned to Author". The Style Guide says[2] we already have an "In Review" label so I'll put it on my list to check when and for whom it appears. I assume only the curator sees it.

My second observation is that curators are potentially confused about whether they are being to asked to curate an entirely new dataset that has never been published (a combination of the labels "Unpublished" and "Draft" indicates this brand new, never been published status) versus a dataset that has already been published as 1.0 or whatever but now has a post-publication draft (the label "Draft" is present but the label "Unpublished" is absent). It's probably too subtle to expect people to think this hard about the presence or absence of the "Unpublished" label. For now, I hope this helps explain the existing labels. If this isn't documented in the User Guide please do open a GitHub issue. :) Anyway, your proposed solution is to show the version number to the curator because the curator knows that "1.1" means the dataset has already been published and that the author needs review of a post-publication draft. It's a good idea. There's a related GitHub issue at https://github.com/IQSS/dataverse/issues/2782 about bringing back a version indicator on the dataset page that was lost when we made some performance improvements and I think this would help a ton. This is probably out of scope for https://github.com/IQSS/dataverse/issues/3943 but I can at least look into adding the version number to the *notifications* that are sent.

My third observation is that at some institutions, when the author clicks "Submit for Review", the dataset needs to be directed to a curator who knows something about the subject (e.g. Mathematical Studies) and that putting the subject in the notification would help. I like this idea.

Also, I did take note of a new bit of feedback from Steve McEachern at https://github.com/IQSS/dataverse/issues/3943#issuecomment-312400480 where he wrote, "I like where this is going - this is an important workflow for an archive like ADA where the curator often makes a number of edits and modifications prior to publishing, in conjunction with the author." My observation here is that it's expected that this process might look a bit like a tennis match with the dataset bouncing between author(s) and curators(s) before the dataset is ultimately published

Thanks again for this new feedback, Philipp and Steve! I'm glad I asked!

Does anyone else have any ideas they'd like to share?

Thanks,

Phil

1. Dataverse UX&UI and Community Discussion at https://osf.io/pu7yn/ via https://projects.iq.harvard.edu/dcm2017/agenda
2. http://guides.dataverse.org/en/4.7/style/patterns.html#labels

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsubscribe...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/348e2e48-c503-467e-9c45-0828f95f2e4e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steven McEachern]

Hi Phil,

Thanks for picking this up. As you note, we do have a more detailed curation model in mind - and the tennis match metaphor is apt : "this process might look a bit like a tennis match with the dataset bouncing between author(s) and curators(s) before the dataset is ultimately published". Under this model there are often several iterations of communication between the researcher and the curator/archive.

Two points in particular come to mind:

1. There can be a significant amount of information conveyed in those messages, which we would want to capture and preserve as an archive, to support the provenance of the dataset.

2. We don't want to create a chat service - but we do want a formal message service to provide comment back to the author.

This type of workflow is also relevant to other approval processes. Our current ADA use case at the moment is that of Restricted Access datasets. The user requests data, and then the author wants information on the intended use (or the user) - who wants it, and WHY. We are currently extending the Guestbook and Restricted Access functionality to enable this, but would love to see it embedded directly into the main codebase (and have discussed this with Gustavo and Danny).

Can I suggest this might be a good discussion for a community call? I'd be happy to talk about what ADA is doing with Restricted Access, and what some of our interests are in the Submit for Review process.

Cheers,

Steve

[Philip Durbin]

I'm glad you like the tennis analogy. Thu-Mai did too, apparently and I just copied her post on this list to https://github.com/IQSS/dataverse/issues/3943#issuecomment-312964071 because I was afraid it would get lost since the subject was "digest" whatever. She brought up a third party, the journal editors. I suppose that communication should be captured too, some day. Please see the comments I just left in the issue about going from a skateboard to a car.

I'm fascinated to learn that you've got developers hacking away on extending the guestbook and restricted access features! Please send me a link to their code so I can see what they're up to! Please send ask them to subscribe to https://groups.google.com/forum/#!forum/dataverse-dev and introduce themselves! :) Absolutely this work is good fodder for a community call!

Thanks also for jumping in chat the other day and I'm sorry I didn't get a chance to explain what was going through my head when I linked you to the image of undoing a braid. Your developers are working on what I call in GitHub issue labels the "Request Access Workfow". In contrast, in #3943, I'm working on the "In Review Workflow". They're definitely related insofar as communication happens between two parties but I'm working on communication from curator to author and the other workflow is between the author and the person who wants to download the file.

Please keep the ideas coming!

Phil

--

You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsubscribe...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/fbf5022c-9059-4b8c-b7a4-94dc7dafa371%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sebastian Karcher]

Thanks everyone. We, too, are very keen on this and for the most part I just want to say +1 to everything Steve has been saying here and on github. This is now a lot to read and I skimmed some of it, so please forgive if I missed something.

In particular, while I understand your concerns about scope creep, capturing the back and forth with the authors in the curation process would be super helpful for us -- there is essentially always a back and forth involved rather than just a passive "depositor does what curator tells them to." We'd want this not just in terms of audit trail, but also to have all information in one place rather than jumping back and forth between e-mail and the deposit&curation system.

One place where this is particular important is the decision on the type and level of restrictions we place on files, which we have to discuss at the file level.

Also 2nd the "returned to author" -- the "In Review" tag (while helpful) appears when we are actually reviewing the data. It'd indeed be great if a dataset returned to the author wouldn't just return to look like one just begun (tags: unpublished, draft) but have a distinctive tag, to replace tag ("returned to author" as suggested or something of the kind).

The last thing is something that came up in the curation lunch table from the folks at Dryad. They have a category of files that are part of dataset that are only visible (as opposed to accessible) internally (i.e. in DV categories for Curators and Administrators). I could see various uses for this -- signed agreements with the depositors or post-deposit consultations about access to restricted data. I think Sonia actually keeps such notes in the Harvard ticketing system currently. Pretty sure more uses where mentioned, but this would be a very useful & versatile future for curating data repositories.

We've all very excited to see this moving forward and the broad interest in this and would definitely join a community call on the topic.

All best,

Sebastian (Qualitative Data Repository)

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse-community@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABbxx8F-HG_xFHDC27FhUY69S92vKkzq5h1oNF0TjyS5TWhE%2BQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sebastian Karcher, PhD
www.sebastiankarcher.com

[Philipp at UiT]

I'm not sure whether this belongs to this thread, but I would like to add a suggestion, or rather a thought about the communication flow between depositor and curator. At our university, quite a lot of services use a ticketing system (cf. https://bestpractical.com/). We are also considering using this system to handle research data management support. The idea is that researchers can send their questions to *one* email address, and they would then be answered by different people according to the subject (e.g. general questions, questions about licensing, IPR, sensitive data, storage facilities etc.). However, I'm now wondering how this system could interact with the depositor-curator workflow in Dataverse. Ideally, we would like to configure our Dataverse so that system messages to curators are sent to the ticketing system. But I guess this would depend on the email address of the curators to be identical to the ticketing system address. However, Dataverse does not allow more than one user to have the same email address.

Does anyone have any experiences with integrating Dataverse messages with a ticketing system?

Best,

Philipp

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/fbf5022c-9059-4b8c-b7a4-94dc7dafa371%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABbxx8F-HG_xFHDC27FhUY69S92vKkzq5h1oNF0TjyS5TWhE%2BQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Steven McEachern]

@Phillipp@Uit We don't have this experience yet - but it's definitely on my radar!! We looked at RT but there's a fair bit of overhead there, and so I've been thinking about others as well (Zoho is our current one for testing). I'd also like to hear thoughts on other systems too.

Cheers
Steve

[Philip Durbin]

A few updates. Thanks, Sebastian, joining the fray here and in the issue. I definitely had audit trail on my mind today. I'm at least playing with code along these lines.

Even if we allow the author to write back some day, it's probably inevitable that not all communication will be captured in Dataverse. What if the author and the curator bump into each other in the hall? They must not communicate. ;) Go back to Dataverse and type in the box. :)

It sounds like there's lots to unpack about file restrictions and the "request access" workflow. I'm trying to keep the focus on the "return to author" workflow but it's interesting that you seem to be saying you may be interested in capturing forever the back and forth between the person requesting the file and the person granting access. Right now there is no back and forth (no boxes to type in) and from my understanding we don't persist any history of file access requests once the decision has been made to grant or deny access. I'm a little fuzzy on visible vs. accessible but again, I'm trying to control the scope of what I'm working on so I'm not going to worry about it right now. :)

Philipp, I've been using RT for over 10 years and I like it well enough (I've even played with its API) but I don't think we plan to integrate it into Dataverse any time soon. It's not a bad idea and I wonder if systems similar to Dataverse have integrations like this. I guess Dataverse isn't really in the business of receiving email, which is probably a good thing considering how much spam there is out there. Like you say, people are welcome to attempt their own integrations. For our part, I think we should just continue to expose as much functionality as possible via Dataverse APIs and allow whatever integrations come along to blossom.

Anyway, please keep the ideas coming.

Thanks!

Phil

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse-community@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/40292acd-4f56-484e-8016-55b6daec72e3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Janet McDougall - Australian Data Archive]

hi Sebastian

I've been recently looking at how far Dataverse can anticipate the ingest/curation/preservation process, and your comments about "only visible (as opposed to accessible) internally (i.e. in DV categories for Curators and Administrators)"  have given me some ideas for how to potentially utilise this feature...

Thanks

Janet

The last thing is something that came up in the curation lunch table from the folks at Dryad. They have a category of files that are part of dataset that are only visible (as opposed to accessible) internally (i.e. in DV categories for Curators and Administrators). I could see various uses for this -- signed agreements with the depositors or post-deposit consultations about access to restricted data. I think Sonia actually keeps such notes in the Harvard ticketing system currently. Pretty sure more uses where mentioned, but this would be a very useful & versatile future for curating data repositories.

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/fbf5022c-9059-4b8c-b7a4-94dc7dafa371%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABbxx8F-HG_xFHDC27FhUY69S92vKkzq5h1oNF0TjyS5TWhE%2BQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.