Improve contributor entry during submission

[NateWr]

Describe the problem you would like to solve
It can be slow and tedious to enter contributors when an author is making a submission. The author may not know the details of all authors, resulting in stalled submissions or inaccurate data. Furthermore, most of the information is not required during submission, but only in time for publication.

Describe the solution you'd like
During submission, authors should only be asked for a minimum amount of information about contributors. Where possible, the system should try to automate the collection of information about contributors. The system should also ask contributors to authenticate their ORCID, confirm their details, as well as specify their contributions, in line with the CRediT schema, rather than relying on the submitting author to provide all information.

The mockup below shows a proposal for the contributor step during submission. This would allow the submitting author to enter the contributors' email address or ORCID id. The system would then try to locate the contributor details automatically. If it can't, it will save the email address. When the submission is completed, all contributors would be sent an email with a link to view their entry, change their details, define their CRediT contribution, and confirm their listing.

Who is asking for this feature?
Disciplines that publish articles with a large number of contributors (50+).

Additional information
Author-less publications and institutional authors would need to be considered with this approach.

Usability testing was carried out on this mockup, as part of #7191, with the following recommendations:

• The add contributor form was hard to find below the text on the left. It should probably appear in the main panel on the right.
• Allow a "contributing author" to be specified, alongside the "submitting author".

[ajnyga]

Just adding a note here on contributor roles.

I think a lot of our problems derive from the fact that we try to use the same taxonomy of user roles both for:

1. Handling user permissions in the system, ie. what can a user do with a specific role
2. In article metadata desrcive the contributors role

I think we should just separate these two very different things completely.

We should take Credit into account, but it will not solve some of the problems that we have in upstream use of contributor data. While it does have a wide variety of roles described, they are actually a) very hard to understand if you show them on the article landing page and b) not very functional for some common purposes, for example telling the difference between the author and the translator, or author and the volume editor.

For example in ORCID, we need to be able to say if the contributor is a translator. We have no good way of doing that: https://github.com/pkp/orcidProfile/blob/main/OrcidProfilePlugin.php#L74

Also, in OMP we would need to able to say which users are volume editors and which are chapter authors: https://forum.pkp.sfu.ca/t/omp-doi-plugin-how-to-export-crossref-xml/49631/30

ORCID has their own taxonomy for contributors that has a very functional approach we would benefit of. They also support Credit. https://info.orcid.org/ufaqs/what-contributor-information-should-i-include-when-adding-works-or-funding-items/

We should define our own set of Contributor Roles we could then use for mapping to other taxonomies in upstream use. Basically determine a set of roles that work in most cases, like Author, Chapter Author, Editor, Translator etc.

So when adding a contributor to the submission, you could select both the Contributor Roles the contributor has (for example in OMP a contributor can be both Chapter Author and Volume Editor at the same time) and you could also add which Credit roles apply to the Contributor.

[NateWr]

I agree that there is ambiguity between a formal set of roles used in metadata (Credit, ORCID, Crossref) and the configurable roles system OJS uses in themes. Standardizing on something for the metadata, and leaving our configurable roles as a layer on top, is probably the best approach.

I think it's a different issue than this, though. You could make a proposal in #857 or consider opening a discussion.

[ajnyga]

I revised a bit better comment to the issue you suggested #857 (comment)