I’m trying to set up my journal with a delayed open access policy, such that issues published with Access status “Subscription” are automatically converted to “Open access” 24 months after the date of publication. There, however, seem to be a few ambiguous options in the settings, which have me confused.
I’d guess the correct step to achieve this would be to set Subscriptions → Subscription Policies → Open Access Options For Subscription Journals to “24 months”.
Despite setting this though, I’m still presented with the option of setting the Access status to either “Subscription” or “Open access” when publishing an issue. I’m not quite sure how this is managed with respect to the “24 months” option chosen under Subscription Policies. Does it work such that if I choose “Open access” status when publishing, it remains open access forever, but if I choose “Subscription”, it automatically converts to “Open access” 24 months after the set value for “Date Published”?
Another confounding setting is the “Open access date”. Shouldn’t this be figured out automatically from the “Date Published” and “24 months” setting? Does setting a date here override that setting?
Just a quick followup question to this. What exactly does checking the checkbox “Registered readers will have the option of receiving the table of contents by email when an issue becomes open access.” under Payments → Subscription policies do? Even after checking this box, upon logging in under a test reader account and navigating to Dashboard → Notifications, I only see an option for “An issue has been published.” under Public Announcements, which I presume will send the reader a notification when a new issue has been published, and not when an older issue has changed status from Subscription to Open access.
Registered readers will have the option of receiving the table of contents by email when an issue becomes open access.
…is checked, and if scheduled tasks are set up in config.inc.php, then when an issue becomes Open Access (i.e. moves out of the embargo period), anyone registered with the journal as a reader should receive an email based on the OPEN_ACCESS_NOTIFY email template.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks a lot for that clarification. Just a suggestion though. It might be helpful to make that clearer in the Public Notifications section of the Notifications tab, in the Dashboard of a reader. From the way it currently appears, a reader would expect him/her to be notified whenever an issue is published, not when it transitions to Open Access.
Additionally, would really appreciate a response to the questions in my first post of this thread if you have a few moments.
Use the setting to pre-fill the open access date for an issue.
I see you’ve suggested #2 above, but my only hesitation with that is that it’s not clear when that field should be set, and if that happens after an issue is already created, filling in the date later might be unexpected for the user who has already reviewed that field and intentionally left it blank. Opinions?
The operative field for delayed open access, as you’ve guessed, is the date attached to the issue. When that date is reached, the issue becomes open access.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks a lot for shedding some light on this. I agree that Option 1 (removing this setting) probably makes the most sense considering the issues you highlighted. I’m sure our editor and others would prefer to have manual control over when issues become open access, without any automated mechanism to do this based on a timer.
I took another look at this in preparation for removing the setting but have to correct myself: the setting is in fact used. When an issue is published, the open access date is automatically assigned based on the embargo duration.
I’m still inclined to remove this setting, as IMO it might surprise editors who have manually set (or intentionally left un-set) the open access date before publishing the issue. Does that still sound like the most reasonable approach to you?
Regards,
Alec Smecher
Public Knowledge Project Team
Frankly, either option seems fine to me as long as it is clear in the documentation about how this open-access date is managed. I don’t think our editor would mind setting this date manually. Even if it is automatically set upon publishing an issue (which I’m not completely sure works from the last few test issues I’ve published - I’ll have to get back to you on that), I think that’s okay as long the documentation mentions this somewhere.
