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

Add options list to version justification: type of amendment #4

Open
felixhelix opened this issue Jun 27, 2024 · 10 comments
Open

Add options list to version justification: type of amendment #4

felixhelix opened this issue Jun 27, 2024 · 10 comments

Comments

@felixhelix
Copy link

Thanks for this great plugin :)
We have as an additional requirement that the author needs to state which type of amendment has been made to the previous version. So I forked the plugin to add a select list with the options "Update", "Revision" and Correction. The exact meaning is given in our publication guidelines.
I just wonder if such a list is also of interest to your users. in which case I could make a pull request so I do not have to maintain a seperate version :)
We're running OPS version 3.3, but we plan to switch to OPS 3.5 when it is published. So I have to implement the changes to work with 3.5 in any case.
Just let me know.
Yours
Felix

@felixhelix felixhelix changed the title Add select: type of amandment Add select: type of amendment Jun 27, 2024
@felixhelix felixhelix changed the title Add select: type of amendment Add options list to version justification: type of amendment Jun 27, 2024
@diegoabadan
Copy link
Member

Thanks, @felixhelix !

We'll talk to our colleagues at Scielo Brasil, who are the creators and funders of this plugin, and get back to you. Due to the vacation of our main contact at Scielo, the return may not be until the end of the month.

Scielo Preprints should update soon to OPS 3.4 and to 3.5 when it is stable. So we should be back on 3.5 soon!

@alexxxmendonca
Copy link

Hello @felixhelix !

Thank you very much for your interest in contributing to our plugin. We appreciate it.

We think it's a very good idea and actually, it's something that we've been wanting to include.

However, we would like to understand better the three options:

  • Minor updates
  • Revised version
  • Corrected version (after retraction)

I'm concerned whether authors would know the difference between "Minor updates" and "Revised version". In fact, isn't "minor updates" a "revised version", still?

I am also curious to know in which scenario "Corrected version (after retraction)" would be used. It's not clear to me if retracted papers get to have a revised version. Once a paper is retracted, are authors allowed to submit a revised version?

@felixhelix
Copy link
Author

felixhelix commented Aug 15, 2024

@alexxxmendonca Thanks for your questions and your interest!
The options are tailored to our policies, which explain the differences:

  • "Minor updates" "are typically limited to fixing typographical errors, or updating affiliations or contact details, authorship, and acknowledgment information."
  • "Revised versions" refers to new versions after peer review (we support open peer review).
  • "Corrected version": A publication may be retracted for several reasons. If authors are able to make sufficient corrections, they can post a new version: "Corrections are appropriate if only a small portion of an otherwise reliable manuscript proves to be misleading (especially because of honest errors). In such instances, authors may submit a corrected version of the article providing a summary explaining what was corrected and why."

As said, these are very much tailored to our policies, so one may want to think of making the list of options configurable. In any case, server managers can overwrite the default locales by using the "custom locale plugin". So if you can think of other options, we would be o.k. with this :)

Yours,
Felix

@alexxxmendonca
Copy link

Hi @felixhelix

Thank you for explaining!

Would you be okay if we only had two options?

  • Minor revisions
  • Major revisions

Assuming the scenario where a paper is retracted and authors are asked to submit a corrected version. Couldn't that fall into the "Major revisions" category?

@felixhelix
Copy link
Author

felixhelix commented Aug 19, 2024

Hi @alexxxmendonca,

I have discussed this with my colleague, and we clearly see the need for three options:

  • Revisions
  • Corrections
  • Updates

The reason is, that they occur in different contexts / for different reasons:

  • Revisions are about improving and enhancing a piece of work overall - usually after peer review.
  • Corrections may be needed because a manuscript contains critical errors that significantly impact the credibility of its findings and conclusions. These can result from honest errors, miscalculations, or more severe instances of scientific misconduct. Corrections are appropriate if only a small portion of an otherwise reliable manuscript proves to be misleading (especially because of honest errors). This would be a case where a retraction could have occured before.
  • Updates signal minor changes - typically limited to fixing typographical errors, or updating affiliations or contact details, authorship, and acknowledgment information."

That is, if we only have two options such as minor or major revision, that would not signal the context or the reason, but just say something about the amount / quantity of change (which could also lead to discussions). Our suggested options on the other hand say something about the quality of the change.

Yours
Felix

@alexxxmendonca
Copy link

alexxxmendonca commented Aug 20, 2024

Hello @felixhelix

Thank you for the explanation.

After some consideration, we came to the conclusion that these options might cause confusion for authors sending their revised versions. The options you suggested are based on your editorial policy, but not necessarily they represent a common consensus within the scientific community.

"Revisions" and "Updates" are both very similar terms, for example.

For that reason, we will kindly decline this feature request, but we're open to discuss this again until we reach some consensus.

I hope you can understand.

@felixhelix
Copy link
Author

felixhelix commented Aug 23, 2024

Hello @alexxxmendonca
Thanks for considering our request :)

I see part of the problem as a result of science being focused on publications in journals and not in valuing and making transparent the scientific process. So the vocabulary here is not yet established (and may well need to be developed further).

What we want for our project, however, is some marker as to what the change in the preprint results to. Of course one can write it in the version justification, but we want some fixed terms. There are multiple reasons for this:

  • not all types of new versions require a new review round
  • standardized types for new versions could be included in the metadata (at some later time)
  • readers know at a glance if re-reading the new version could be worth their time

We also envision a kind of subscription that informs readers when a new version is out. Besides seeing immediatly if the new version is worth reconsidering, readers could also just subscribe to new versions that are revisions or corrections. (oh, that could as well be a new feature request ;)

One way to adress the problem of intelligibility that you mentioned could be to provide a description about what the terms "revision", "correction" and "update" imply - By that we would also raise the consciousness about such issues :)

Yours
Felix

@diegoabadan
Copy link
Member

In this scenario where there is not yet a shared vocabulary across the community, and different editors may want specific markings for versions, one solution would be to allow the use of tags defined by each server freely.

Server A would have the tags 'major change' and 'minor change'. Server B would have “revision”, “correction” and “update” and so on.

We also envision a kind of subscription that informs readers when a new version is released. As well as immediately seeing if the new version is worth reconsidering, readers can also subscribe to receive new versions that are revisions or corrections. (oh, that could also be a new feature request ;))

I think the option to sign up to be notified of new versions is great! However, I would keep it as simple as possible, without this granularity of being able to receive notifications by type of change.

This feature could be proposed as something native to OJS.

@alexxxmendonca
Copy link

Great suggestions, @diegoabadan

I am ok with that!

@felixhelix
Copy link
Author

felixhelix commented Sep 5, 2024

Thanks @diegoabadan for your suggestions: This sounds promising :)
What kind of implementation for the tags do you think of: something like the tagit fields (as for keywords etc.)?
Yours
Felix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants