Remove figshare form documentation #1434
Conversation
|
I opened a discussion on slack, as I can't find the original discussion there, and would like to understand why we might make this change. |
|
Rather than having different docs in different places, can we try to have consistent language. Maybe we could try to make the points that we want a repository that ideally supports software licenses, ORCIDs for authors, a version tag that matches the content (not just the number of deposits in the archive, etc.), and then say that Zenodo is an example of a repository that meets these goals, but that any r3data.org repository would be ok. Some people are likely required to use institutional repositories as well. What do you think? |
This sounds like a good solution! We should specifically point what a repo needs to support. |
|
Yes, I like that. I can change the pull request accordingly. |
|
@jromanowska and @danielskatz it took a while but I did a new pass. Please have a look. |
| ## Post-review | ||
|
|
||
| When a submission is ready to be accepted, we ask that the authors issue a new tagged release of the software (if changed), and archive it (on [Zenodo](https://zenodo.org/), [fig**share**](https://figshare.com/), or other). The authors then post the version number and archive DOI in the `REVIEW` issue. The handling editor executes the pre-publication steps, and pings the Track Editor-in-Chief for final processing. | ||
| When a submission is ready to be accepted, we ask that the authors issue a new tagged release of the software (if changed), and archive it on a service that ideally supports key features such as software licenses, author ORCIDs, and version tagging aligned with the actual content (rather than merely reflecting the number of archive deposits). One suitable example is [Zenodo](https://zenodo.org/). The authors then post the version number and archive DOI in the `REVIEW` issue. The handling editor executes the pre-publication steps, and pings the Track Editor-in-Chief for final processing. |
There was a problem hiding this comment.
I don't think we can say "ideally". We need to state firm requirements. And I don't really understand a lot of the text here.
Also, I don't think "version tagging aligned with the actual content (rather than merely reflecting the number of archive deposits)" is really a requirement. If this is just a preference, we should drop it from the text.
| ### Setting the software archive | ||
|
|
||
| When a submission is accepted, we ask that the authors to create an archive (on [Zenodo](https://zenodo.org/) or other) and post the archive DOI in the `REVIEW` issue. The editor should ask `@editorialbot` to add the archive to the issue as follows: | ||
| When a submission is accepted, we ask that the authors to create an archive and post the archive DOI in the `REVIEW` issue. The editor should ask `@editorialbot` to add the archive to the issue as follows: |
There was a problem hiding this comment.
I don't see how this change is helpful. It seems more confusing (with less information) to me.
| - **JOSS reviews are iterative and conversational in nature.** Reviewers are encouraged to post comments/questions/suggestions in the review thread as they arise, and authors are expected to respond in a timely fashion. | ||
| - Authors and reviewers are asked to be patient when waiting for a response from an editor. Please allow a week for an editor to respond to a question before prompting them for further action. | ||
| - Upon successful completion of the review, authors will make a tagged release of the software, and deposit a copy of the repository with a data-archiving service such as [Zenodo](https://zenodo.org/), get a DOI for the archive, and update the review issue thread with the version number and DOI. | ||
| - Upon successful completion of the review, authors will make a tagged release of the software, and deposit a copy of the repository with a data-archiving service, get a DOI for the archive, and update the review issue thread with the version number and DOI. |
There was a problem hiding this comment.
I don't see how this change is helpful. It seems more confusing (with less information) to me.
I also don't think "data-archiving service" is the right thing here. I think better wording would be something like "an archival repository that meets ... requirements" where we also point to what the requirements are.
I removed figshare from the documentation as discussed on slack.
There is still one occurrence left here: https://github.com/diehlpk/joss/blob/b9c760c2ccb73fd4aeb7d94a769d9b114d31f42b/spec/models/paper_spec.rb#L158