Consider a base SubmissionGroup class Issues, Sections, Categories, etc

[NateWr]

This issue splits off from a previous conversation and proposal about a possible base class, SubmissionGroup.

I can see that [themed collections] is going to attract a lot of knock-on requests (assigned editors, DOIs for collections, sorting, scheduling, descriptions/cover images/introductory articles, one-off collections vs rolling collections and continuous publishing). Looking beyond 3.2, I wonder if we should explore a base SubmissionGroup class where we house these features, and on top of which we can build Issues, Sections and Collections, cater better to Special Issues, and also bring in common functionality from OMP's Series and Categories?

Here's a first-draft brainstorm using the following types of submission groups:

• Issue - As-is with some extra stuff for special issues
• Collection - One-off collections of previously published material
• Section - Submission types (Articles/Reviews/etc)
• Series - Book series'
• Category - Continuous publishing, pre-prints, thematic groups, and mega-journal subjects
• Tags - Custom assigned labels/tags for managing submissions as a group in the editorial submission list (eg - filters)

Feature	Issue	Collection	Section	Series	Category	Tags
Allow authors to submit to this group	✓ (special issues)	✓	✓	✓	✓
Allow editors to submit to this group	✓ (special issues)	✓	✓	✓	✓
Submissions are/aren't peer reviewed	✓	✓	✓	✓	✓
Automatically assign editors	✓	✓	✓	✓	✓
Path, description, title and cover image	✓	✓	✓	✓	✓
DOIs	✓	✓	✓	✓	✓
Sorting defaults	✓	✓	✓	✓	✓
Manual sorting override	✓	✓	✓	✓	✓
Option to display published articles or any submissions passed X stage	✓	✓	✓	✓	✓
Schedule for later publication	✓	✓	✓	✓	✓
Unpublishing/Disable	✓	✓	✓	✓	✓
Page that lists all groups (eg - Archives)	✓	✓	✓	✓	✓
Page that lists all articles by group (eg - Browse By)		✓	✓	✓	✓
Vol/No/Year and combined "identification"	✓
Current/latest group	✓	✓
Introductory article(s) with contributors/metadata		✓
Group-specific submission policies		✓	✓	✓	✓
Do not request abstract during submission	✓ (special issues)	✓	✓		✓
Abstract length restrictions (OJS)	✓ (special issues)	✓	✓		✓
Identify items as			✓
ISSN				✓
Nested Groups					✓
Control over URL structure		✓			✓
Ability to assign from Submission list		✓				✓

@ajnyga comment

• Not all items listed can receive DOI.

The original conversation includes a good discussion of preprints, and whether or not they make sense as a SubmissionGroup. I will not copy that into this issue but it is worth reading.

[ajnyga]

(just to be more specific, all of them probably can get a DOI technically, but for example Crossref probably does not allow registering of each type)

[NateWr]

I added a new type of SubmissionGroup for labelling or tagging submissions to group and manage them in the submissions list. This would be an arbitrary tag/label that editors could assign to a submission from the list, similar to GitHub labels.

This request was mentioned multiple times in the TC's community survey from 2021.

[denismaier]

May I kindly ask what the status of this is? Has there been any activity on this?

[NateWr]

No, no activity on this recently. We have converted it to a discussion, which means it's not scheduled for work at any point in the future.

[denismaier]

Hmm, what can be done to change that?

[denismaier]

For context, there are related issues like this one: #5752 that would probably be superseded/covered by the proposal here. I would very much like to see the feature from #5752 coming, but obviously, if there were plans for a more complete change that would cover this, that would be even better ...

[NateWr]

You can register a vote on the initial comment above, which gives us a rough estimate of the amount of support a proposal has.

However, I don't want to raise your expectations too high. This is one of those technical changes that would require a large amount of tricky refactoring work without many improvements for the end user. It is really hard to prioritize such changes with our limited development team. Unfortunately, it is not the kind of work that can be done through a community contributor, because such a change requires an enormous amount of oversight.