lepidus / authorVersion

GNU General Public License v3.0
3 stars 1 forks source link

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

Open felixhelix opened 2 months ago

felixhelix commented 2 months ago

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

diegoabadan commented 2 months ago

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 commented 1 month ago

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:

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 commented 3 weeks ago

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

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 commented 3 weeks ago

Hi @felixhelix

Thank you for explaining!

Would you be okay if we only had two options?

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 commented 2 weeks ago

Hi @alexxxmendonca,

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

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

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 commented 2 weeks ago

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 commented 2 weeks ago

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:

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 commented 3 days ago

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 commented 3 days ago

Great suggestions, @diegoabadan

I am ok with that!

felixhelix commented 2 days ago

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