Implementação do OJS: checklist antes de publicar uma revista

Veja o que uma implementação do OJS deve incluir: papéis, e-mail, políticas, testes e entrega documentada antes de lançar sua revista universitária.

Uma implementação do OJS deve ser recebida com um fluxo testado e responsabilidades documentadas, não apenas com um endereço web que abre. Se você precisa aprovar a entrega para uma revista universitária, recomendamos verificar o que cada participante pode fazer, como os envios são recebidos e quem resolverá as pendências após o encerramento.

O OJS é um software de código aberto da PKP que cobre o site da revista e o processo de submissão, avaliação, edição e publicação.[8] Essa amplitude justifica combinar um escopo concreto: ter a plataforma disponível e estar preparado para publicar são verificações diferentes.

Combinar qual serviço está sendo recebido

Convém separar a implementação pontual de outros trabalhos antes de revisar as telas. Como critério de contratação, recomendamos deixar estas diferenças por escrito:

A implementação entrega uma configuração inicial acordada e evidências dos testes.
A atualização altera uma instalação existente e precisa de escopo próprio.
A operação recorrente define quem cuidará da continuidade técnica após a entrega.
A produção de artigos trata dos arquivos destinados à publicação e deve ser combinada separadamente.

As decisões científicas continuam sendo da revista. Recomendamos que sua direção aprove as políticas, os critérios de avaliação e as decisões sobre manuscritos; o fornecedor configura o que foi definido, sem substituir essa responsabilidade.

Um documento breve pode indicar entregáveis, exclusões, dependências institucionais e critérios de aceitação. Se a universidade ainda não forneceu uma conta de e-mail, por exemplo, convém registrar essa dependência em vez de dar o teste por concluído.

Revisar identidade, políticas e permissões

Recomendamos comparar a configuração com uma ficha aprovada pela revista: nome, descrição, contato editorial, idiomas de trabalho e responsáveis. Os textos de apresentação e as políticas devem ter uma pessoa que os valide, ainda que outra pessoa os insira no sistema.

Convém revisar as instruções para autores, a descrição da avaliação, as condições de publicação e as declarações solicitadas durante a submissão. Este artigo não define seu conteúdo: recomendamos que a revista o resolva conforme suas decisões editoriais e institucionais.

Testar com o papel que cada pessoa usará

O OJS distingue níveis de acesso: o gerente da revista pode acessar o fluxo e as configurações; o editor de seção trabalha no fluxo sem esse acesso às configurações, e os avaliadores acessam as submissões que lhes foram atribuídas.[7]

Por isso recomendamos receber uma matriz simples de pessoas, papéis e tarefas autorizadas. O teste deve ser feito a partir dessas contas, e não apenas de uma conta com permissões amplas. Também convém identificar quem poderá gerenciar cadastros, substituições e desligamentos, e entregar as credenciais por um meio combinado, fora da ata pública.

Verificar o e-mail e o percurso editorial

Recomendamos realizar uma submissão de teste completa antes de abrir a recepção real. Ela deve usar identidades e documentos fictícios, claramente identificados, para não misturar a aceitação do serviço com manuscritos confidenciais.

A evidência pode registrar a entrada da submissão, sua atribuição, uma avaliação simulada, uma decisão de teste e a preparação de uma publicação em ambiente não público. Em cada etapa, convém anotar a conta utilizada, o resultado esperado e o que foi observado.

Quanto ao e-mail, recomendamos verificar o remetente, o endereço de resposta e a recepção efetiva nas caixas de teste combinadas. Que uma notificação apareça na tela não basta como critério de recepção. Se uma mensagem não chegar, a ata deveria distinguir o problema observado de sua causa, que pode exigir revisão técnica.

Exemplo hipotético de recepção

Uma biblioteca recebe uma revista nova. A página inicial está pronta, mas durante a submissão fictícia o editor não recebe o aviso esperado. Recomendamos registrar esse ponto como pendente e repetir o teste depois de corrigi-lo. O exemplo não descreve um cliente real nem supõe que todos os problemas de e-mail tenham a mesma solução.

Validar metadados e deixar os DOI com status explícito

Convém combinar uma amostra fictícia para revisar títulos, autorias, afiliações, resumos, idiomas e arquivos de publicação. Recomendamos comparar o que foi inserido com o que o leitor verá e confirmar quem fará essa revisão nos conteúdos reais.

Se o projeto prevê DOI, recomendamos documentar a agência correspondente, a responsabilidade institucional, as credenciais disponíveis e o escopo contratado para configuração e testes. As chaves devem ser trocadas por um canal seguro, e não incluídas na ata.

Como critério de aceitação, convém distinguir entre uma configuração preparada e uma operação comprovada. Não recomendamos aceitar a expressão "DOI pronto" sem especificar o que foi verificado. Tampouco se deve presumir a atribuição ou o registro automático: qualquer automação prevista precisa de uma verificação específica dentro do escopo combinado.

Checklist para a ata de aceitação

Recomendamos usar esta lista como base de uma revisão conjunta. Cada ponto deve ficar aceito, pendente ou fora do escopo, com evidências quando couber:

A revista aprovou sua identidade, contatos, idiomas e textos editoriais.
As pessoas responsáveis testaram seus papéis com contas próprias.
A submissão fictícia percorreu as etapas combinadas sem publicar material de teste.
As mensagens previstas chegaram às caixas usadas no teste.
A amostra de metadados e arquivos foi revisada pela revista.
O status da configuração de DOI e suas dependências está explícito.
Os acessos e a documentação foram entregues pelos meios combinados.
As pendências têm responsável e condição de encerramento.
A continuidade técnica foi atribuída, incluindo a gestão de backups e a recuperação.

Encerrar a entrega sem deixar a continuidade vazia

Recomendamos que a ata identifique quem recebe o serviço, quais evidências revisou e quais condições ainda impedem abrir as submissões ou publicar. Uma captura de tela isolada não deveria substituir a verificação do percurso combinado.

A PKP observa que operar o OJS como serviço web requer um administrador de sistemas competente.[8] Por isso convém combinar quem ficará responsável pelo servidor, pelos backups, pelas atualizações e pelo atendimento de incidentes após a implementação. Não recomendamos presumir que essas tarefas ficarão a cargo do editor.

A OJS ONE descreve serviços de implementação, operação, suporte, backups e atualizações com testes.[11] Você pode revisar o escopo geral em serviços OJS da OJS ONE. Para avaliar uma implementação concreta, entre em contato com a OJS ONE informando o estado da sua revista e os entregáveis que precisa validar. O escopo aplicável deve constar da proposta acordada.

Perguntas frequentes

O que uma implementação do OJS deve incluir antes de publicar uma revista?

Deve incluir uma configuração aprovada pela revista (identidade, políticas e idiomas), papéis testados com as contas de cada pessoa, uma submissão fictícia completa, e-mail verificado, uma amostra de metadados revisada e o status dos DOI explícito. Tudo deve constar de uma ata de aceitação com pendências e responsáveis.

Qual é a diferença entre implementar, atualizar e operar o OJS?

A implementação entrega uma configuração inicial combinada, com evidências de testes; a atualização altera uma instalação existente e precisa de escopo próprio; a operação recorrente define quem cuida da continuidade técnica (servidor, backups e incidentes) após a entrega. Convém deixar essas diferenças por escrito.

Como verificar se o e-mail e os papéis do OJS funcionam?

Com uma submissão de teste completa, que use identidades e documentos fictícios, e com as contas reais de cada papel, e não com uma conta de permissões amplas. Quanto ao e-mail, verificam-se o remetente, o endereço de resposta e a recepção efetiva em caixas de teste; que a notificação apareça na tela não basta.