donders-research-data-management / rdm-wiki

Technical documentation for RDM
http://donders-research-data-management.github.io/rdm-wiki
1 stars 2 forks source link

DSC contact person #14

Closed robertoostenveld closed 8 years ago

robertoostenveld commented 8 years ago

TBD: Now that we have decided that external researchers, after agreeing with the DUA, are automatically added to a collection as a viewer, I think we do not need the contact person anymore. If external researchers have questions about the data, they may contact the corresponding author of the publication.

robertoostenveld commented 8 years ago

But not all data sharing collections need to have a publication.

I suggest that we allow the selection of one of the authors as the corresponding author and that by default it is the first author (but to be changed in a drop-down menu in the form).

In general not clear to me is how we will provide contact information. E.g. if you look at

https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/BJIAKI

you see there is a contact person name and a built in "click here for contact" button that uses the system to send email. In principle we could implement that as well (allowing each user with an account to be contacted).

This raises a more general concern about contacting: how would I contact all coworkers on a collection. E.g. if a serious flaw is discovered in a DSC, would it be possible to send all viewers an email?

hurngchunlee commented 8 years ago

I can think of the following scenarios of implementation:

  1. in the detail page of the closed data-sharing collection, all managers and contributors are click-able to toggle user's mail client to send a email (this is simple and can be done via the "mailto:" URL). For example: Hurng-Chun Lee contact
  2. similar to scenario 1, but only the first author is click-able. We used to discuss ways to allow a collection manager to construct a "creator/author" list from managers and contributors at the time the collection is closed. There is a attribute called creatorList for storing the list.
  3. similar to scenario 2, but instead of using the email client with "mailto:" link, use the CMS portal to send internal message. Like what Robert proposed with the dataverse approach. Development of this approach is more complex than the above two scenarios, as we need to manage messages and make the system notify the contact person. On the other hand, the advantage is that the interactions w.r.t. data sharing can be monitored.
robertoostenveld commented 8 years ago

I like your 1 more than your 2. But both 1 and 2 are prone to email scraping, e.g. http://www.scrapebox.com/email-scraper

3 has advantages, but requires considerable more work to implement technically and would require us to figure out (i.e. require time) what kind of interactions should be possible (one to one, one to all, whether comments should also be shared publicly, etc.).

I think that initially we should go for option 1. @EricMaris do you agree?

hadrianswall commented 8 years ago

I agree to go for option 1 initially.