-
Notifications
You must be signed in to change notification settings - Fork 445
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
[OJS] Consolidate information entry into fewer fields #1397
Comments
I like this idea of simplifying these settings. |
I can handle it. Let's talk during the next call or, if there's an opportunity, during the sprint. |
Definitely a good candidate for a drunken pull request event. |
Do we plan to support categories in OJS 3? Any idea how I can enable them?
|
Settings > Journal > Policies includes two checkboxes: The latter is very similar to I'm going to just drop them completely unless someone tells me they're needed, in which case I can move them over to the Settings > Workflow > Review form. |
PRs with some big cutbacks: ChangesRemoved:
Moved:
Kept:
New:
CleanupI think we could probably remove some more code that's running the grids on the Sponsors tab. |
Regarding #1397 (comment): The Acronym is used in CrossRef, Refworks, BibTeX, URN and DOI exports, and as a prefix for subjects in email templates. I could maybe argue for a role for both (e.g. "LangSciJ" vs. "LSJ", but wouldn't do it with any enthusiasm. It might be a good idea of we're considering removing one or the other to quickly vet what each external format requires to make sure we're feeding it good data. |
Regarding #1397 (comment): No, I don't think categories (a la OMP, where submissions get categorized according to a controlled vocab) will be all that useful in OJS. A roughly equivalent feature would be to use keywords as the OJS 2.x tag cloud plugin does, which is probably more useful as it gets automatically organized by existing metadata. We did have a different feature (also helpfully called "categories") in OJS 2.x, which was a way of categorizing large sets of journals into topics. But I'm not convinced that is worth rewriting, at least for 3.0. |
Regarding #1397 (comment):
Agreed, probably best to drop them for now. I believe the reviewer settings are accidental duplicates. The author setting will probably need to be hooked up at some point, but I don't think it's a common requirement so it can be post-3.0. |
I did have a least one person specifically ask for categories (as exist in OJS 2) to be transferred to OJS 3. They have multiple journals on one installation and find it helpful (especially for categorizing student journals from professional journals). |
For continuous publishing, categories (as in OMP) could serve a useful purpose in OJS 3. Journals could use a feature much like the Catalogue to organize and display articles on the home page, and in categorized lists. I think it is at least worth considering, even for 3.1. |
For continuous publication, let's leave that discussion to #1407. |
@NateWr, it looks like e.g. the copyright notice is no longer displayed but I don't see that in your notes. |
@willinsky, could you take a glance at Nate's proposal in #1397 (comment) for simplifying the setup fields? Some of those are long-standing OJS fields that I think were devised in an attempt to communicate best practices to editors as much as expose journal workings to outside participants. |
This looks a great consolidation. I don't see the Copyright Policy, which is one I added rewording to and which we have had reasonable requests about encouraging an explicit posting of it. |
Regarding #1397 (comment) on Acronym/Abbrevation: I'm fine just leaving it alone. Regarding #1397 (comment) and #1397 (comment):
Can I strip out the template code for now and start a list of features that may/may not make it for OJS 3.0 (eg - categories/subscriptions)? It can get a bit confusing having these things littering the template files. Regarding #1397 (comment) and #1397 (comment):
The Copyright Notice appears under Settings > Distribution > Permissions, and this is displayed with each article if the checkbox is selected. This is how it is in current Should there be a general Copyright Policy that we encourage to appear in the About the Journal page? If so, I can add it to the list of recommended content in the field description here: @willinsky if there's anything in that description that you think should be added/removed/edited, let me know. |
On #1397 (comment):
Yes, that's probably the best approach.
The Copyright Statement and Copyright Notice are different things. The Copyright Notice is a journal-wide statement of policy that authors might want to read before they submit. It should go in About, and may not strictly apply to all articles (e.g. if it's changed over the years). The Copyright Statement is e.g. "Copyright (c) 2016 by Cholmondeley", which gets stamped on the article as the definitive statement for a piece of content, and that one gets displayed with the article. |
@willinsky, I thought this was going to be more controversial! Are you OK to accept Nate's proposed changes, or would you like to see them in action first? |
@asmecher I've added copyright notice to the list of recommended content for About the Journal. I've also stripped out all the categories code. I may have gone farther than you wanted here and stripped out too much. Take a look particularly at pkp/ojs@19ca023. |
Of course, I'd love to see them in action, but am feeling that this is an improvement and that less guidance is needed now that in the past. |
This commit consolidates several of the various text entry fields into a single aboutJournal field, and removes obsolete settings tabs. This commit effects OJS and OMP.
pkp/pkp-lib#1397 Consolidate settings
pkp/pkp-lib#1397 Consolidate settings
@NateWr, I've merged this into master for pkp-lib, OJS, and OMP after a little further tinkering with tests. I removed the enabled/disabled flag from the Masthead form -- it was only partially implemented there and that was causing problems. (Generally I favour not putting controls like this in multiple places, so I'm happy to leave it on the Admin's "edit" form.) IIRC this merge was holding you up on other stuff -- thanks for bearing with me through some travel delays! Closing the issue, unless there was something still outstanding? |
👍 I'll take a look thanks. |
Aaaa... good to know where it is i.e. is not... :-) Thanks! |
Where was the field, was it a TinyMCE field, what is it for, what content was meant to go in it, how are plugins using it? |
It was on the production stage settings form
|
What is it? The name of the publisher? A description of the publisher? |
Yes, that was the name of the publisher, I think. |
The following PR restores the I believe this issue can be closed once merged. |
pkp/pkp-lib#1397 Restore publisherInstitution field that was removed
Thanks, @NateWr, that's a big one! |
@asmecher Do you think we could make some progress for OJS 3.0 on consolidating all of these different textareas we have for different journal info into a couple basic pages? Here's a list of the data entry we have that feeds into the frontend pages:
I think we could have three textareas for About the Journal, Editorial Team (Masthead) and Submissions.
About the Journal could have checkboxes for whether or not to automatically add the contact information and mailing address, and then would replace the following textareas:
Editorial Team can do what it already does, just loading the Masthead entry:
Submissions can be left largely alone, however I think we could move Author Guidelines into the Settings > Workflow > Submission area and get rid of the Settings > Journal > Guides tab.
The text was updated successfully, but these errors were encountered: