Implementación OJS: checklist antes de publicar una revista

Revisa qué debe incluir una implementación OJS: roles, correo, políticas, pruebas y entrega documentada antes de publicar tu revista universitaria.

Una implementación OJS debería recibirse con un flujo probado y responsabilidades documentadas, no solo con una dirección web que abre. Si debes aprobar la entrega para una revista universitaria, recomendamos comprobar qué puede hacer cada participante, cómo se reciben los envíos y quién resolverá los pendientes después del cierre.

OJS es software de código abierto de PKP que cubre el sitio de la revista y el proceso de envío, revisión, edición y publicación.[8] Esa amplitud justifica acordar un alcance concreto: tener la plataforma disponible y estar preparado para publicar son verificaciones distintas.

Acordar qué servicio se está recibiendo

Conviene separar la implementación puntual de otros trabajos antes de revisar pantallas. Como criterio de contratación, recomendamos dejar estas diferencias por escrito:

La implementación entrega una configuración inicial acordada y evidencia de sus pruebas.
La actualización cambia una instalación existente y necesita un alcance propio.
La operación recurrente define quién atenderá la continuidad técnica después de la entrega.
La producción de artículos aborda los archivos destinados a publicación y debe acordarse por separado.

Las decisiones científicas siguen siendo de la revista. Recomendamos que su dirección apruebe las políticas, los criterios de evaluación y las decisiones sobre manuscritos; el proveedor configura lo que se haya definido, sin reemplazar esa responsabilidad.

Un documento breve puede indicar entregables, exclusiones, dependencias institucionales y criterios de aceptación. Si la universidad todavía no entrega una cuenta de correo, por ejemplo, conviene registrar esa dependencia en vez de dar la prueba por completada.

Revisar identidad, políticas y permisos

Recomendamos contrastar la configuración con una ficha aprobada por la revista: nombre, descripción, contacto editorial, idiomas de trabajo y responsables. Los textos de presentación y las políticas deben tener una persona que los valide, aunque otra persona los ingrese al sistema.

Conviene revisar las instrucciones para autores, la descripción de la evaluación, las condiciones de publicación y las declaraciones solicitadas durante el envío. Este artículo no fija su contenido: recomendamos que la revista lo resuelva según sus decisiones editoriales e institucionales.

Probar con el rol que usará cada persona

OJS distingue niveles de acceso: el gestor de revista puede acceder al flujo y la configuración; el editor de sección trabaja en el flujo sin ese acceso a configuración, y los revisores acceden a los envíos asignados.[7]

Por eso recomendamos recibir una matriz sencilla de personas, roles y tareas autorizadas. La prueba debe hacerse desde esas cuentas, no únicamente desde una cuenta con permisos amplios. También conviene identificar quién podrá gestionar altas, reemplazos y bajas, y entregar credenciales por un medio acordado, fuera del acta pública.

Comprobar correo y recorrido editorial

Recomendamos realizar un envío de prueba completo antes de abrir la recepción real. Debe usar identidades y documentos ficticios, claramente identificados, para no mezclar la aceptación del servicio con manuscritos confidenciales.

La evidencia puede registrar el ingreso del envío, su asignación, una revisión simulada, una decisión de prueba y la preparación de una publicación en un entorno no público. En cada etapa conviene anotar la cuenta utilizada, el resultado esperado y lo observado.

Para el correo, recomendamos comprobar remitente, dirección de respuesta y recepción efectiva en las casillas de prueba acordadas. Que una notificación aparezca en pantalla no basta como criterio de recepción. Si un mensaje no llega, el acta debería distinguir el problema observado de su causa, que puede requerir revisión técnica.

Ejemplo hipotético de recepción

Una biblioteca recibe una revista nueva. La portada está lista, pero durante el envío ficticio el editor no recibe el aviso esperado. Recomendamos registrar ese punto como pendiente y repetir la prueba después de corregirlo. El ejemplo no describe un cliente real ni supone que todos los problemas de correo tengan la misma solución.

Validar metadatos y dejar los DOI con estado explícito

Conviene acordar una muestra ficticia para revisar títulos, autorías, afiliaciones, resúmenes, idiomas y archivos de publicación. Recomendamos comparar lo ingresado con lo que el lector verá y confirmar quién realizará esa revisión en los contenidos reales.

Si el proyecto contempla DOI, recomendamos documentar la agencia correspondiente, la responsabilidad institucional, las credenciales disponibles y el alcance contratado para configuración y pruebas. Las claves deben intercambiarse por un canal seguro, no incorporarse al acta.

Como criterio de aceptación, conviene distinguir entre una configuración preparada y una operación comprobada. No recomendamos aceptar la expresión "DOI listo" sin precisar qué se verificó. Tampoco debe darse por supuesta la asignación o el registro automático: cualquier automatización prevista necesita una comprobación específica dentro del alcance acordado.

Checklist para el acta de aceptación

Recomendamos usar esta lista como base de una revisión conjunta. Cada punto debería quedar aceptado, pendiente o fuera de alcance, con evidencia cuando corresponda:

La revista aprobó su identidad, contactos, idiomas y textos editoriales.
Las personas responsables probaron sus roles con cuentas propias.
El envío ficticio recorrió las etapas acordadas sin publicar material de prueba.
Los mensajes previstos llegaron a las casillas utilizadas en la prueba.
La muestra de metadatos y archivos fue revisada por la revista.
El estado de la configuración DOI y sus dependencias quedó explícito.
Los accesos y la documentación se entregaron por los medios acordados.
Los pendientes tienen responsable y condición de cierre.
La continuidad técnica quedó asignada, incluida la gestión de respaldos y recuperación.

Cerrar la entrega sin dejar vacía la continuidad

Recomendamos que el acta identifique quién recibe el servicio, qué evidencias revisó y qué condiciones impiden todavía abrir los envíos o publicar. Una captura aislada no debería reemplazar la comprobación del recorrido acordado.

PKP señala que operar OJS como servicio web requiere un administrador de sistemas competente.[8] Por eso conviene acordar quién se hará cargo del servidor, los respaldos, las actualizaciones y la atención de incidentes tras la implementación. No recomendamos presumir que esas tareas quedarán a cargo del editor.

OJS ONE describe servicios de implementación, operación, soporte, respaldos y actualizaciones con pruebas.[11] Puedes revisar el alcance general en servicios OJS de OJS ONE. Para evaluar una implementación concreta, contacta a OJS ONE con el estado de tu revista y los entregables que necesitas validar. El alcance aplicable debe quedar en la propuesta acordada.

Preguntas frecuentes

¿Qué debe incluir una implementación OJS antes de publicar una revista?

Debe incluir una configuración aprobada por la revista (identidad, políticas e idiomas), roles probados con las cuentas de cada persona, un envío ficticio completo, correo verificado, una muestra de metadatos revisada y el estado de los DOI explícito. Todo debe quedar en un acta de aceptación con pendientes y responsables.

¿Qué diferencia hay entre implementar, actualizar y operar OJS?

La implementación entrega una configuración inicial acordada con evidencia de pruebas; la actualización cambia una instalación existente y necesita su propio alcance; la operación recurrente define quién atiende la continuidad técnica (servidor, respaldos e incidentes) después de la entrega. Conviene dejar estas diferencias por escrito.

¿Cómo se comprueba que el correo y los roles de OJS funcionan?

Con un envío de prueba completo que use identidades y documentos ficticios, y con las cuentas reales de cada rol en lugar de una cuenta con permisos amplios. Para el correo se verifican el remitente, la dirección de respuesta y la recepción efectiva en casillas de prueba; que la notificación aparezca en pantalla no basta.