Entrega da A1: pool de manuscritos esperando revisão

# Plano de trabalho

**Tema**: pool de manuscritos esperando revisão.

## Objetivo

Para esse trabalho, o objetivo é desenvolver um pequeno sistema no qual seja possível realizar operações relacionadas a manuscritos que ainda necessitem de revisão. I.e., deve haver a opção de autores poderem enviar seus manuscritos para revisão e de revisores poderem listar e avaliar os manuscritos a espera de revisão.

## Estratégia

Na versão atual do *DPublish*, existe o contrato *DPublish*, que serve como um repositório de manuscritos, ligando o ID de um manuscrito ao endereço de seu autor. Dessa forma, conseguímos ter uma forma geral de acessar os manuscritos já publicados.

No entanto, é necessário saber quais manuscritos ainda não receberam uma revisão. Para isso, a partir de um contrato que irá implementar o sistema de revisão, podemos consultar quais manuscritos já receberam revisão ou que tiverem revisões avaliadas como válida.

De qualquer forma, é importante que possamos acessar esse conjunto de dados de uma maneira performática. Dado isso, podemos considerar duas estratégias diferentes:
1. Para cada nova chamada ou mudança no contrato *DPublish*, guardar em um novo contrato o ID dos novos manuscritos, ao mesmo tempo que associa a eles a informação de que ainda não foram revisados. Além disso, também devemos ouvir o contrato que vai implementar a revisão dos manuscritos, verificando se a regra que avalia se um manuscrito ainda espera revisão foi satisfeita para algum dos que ainda não possuem revisão, e modificar seu valor.
2. No próprio *DPublish*, associamos a cada ID de uma publicação uma estrutura de dados que vai conter o endereço do publicador e seu status de revisão. Ou seja, modificamos o *mapping* que existe atualmente para que possa guardar mais dados. Além disso, o contrato que irá implementar revisão deve modificar a variável que indica se o manuscrito está revisado diretamente no contrato *DPublish*.

Essas duas estratégias possuem suas vantagens e desvantagens. Uma vantagem da primeira estratégia é sua implementação quase indolor, sem precisar modificar diretamente outros contratos. A vantagem da segunda estratégia é ter um menor uso de recursos no geral, pois não duplicamos o ID dos manuscritos ou realizamos manipulações muito elaboradas.

Uma vez que alguma das estratégias for implementada, temos que a opção de publicar um manuscrito para revisão é feita de forma automática, assim que um *pre-print* é disponibilizado.

Porém, ainda seria necessário uma interface mais amigável para a consulta dos manuscritos, que pode ser feito em Python e disponibilizado via uma *REST API* ou diretamente em uma interface web para uso final pelos autores e revisores.

## Requisitos

O requisito central desse trabalho é a criação de um contrato de revisão. Sua implementação e interface vão ter bastante influência em como o sistema de manuscritos esperando revisão vai ser feito.

Em quesito de viabilidade, temos situações diferentes para cada uma das estratégias. A primeira necessita que o *Solidity* ofereça a possibilidade de trabalhar com eventos e observadores na escala proposta. Já a segunda requer que haja um esforço coordenado na criação de um bom design dos contratos a serem usados nesse trabalho a fim de garantir que as regras de negócio sejam bem implementadas em cada um deles.

## Cronograma

A priori, o cronograma da realização desse trabalho se baseia no tempo de desenvolvimento dos outros contratos (modificações no *DPublish*, criação do contrato de revisão, etc.). Mas, uma vez isso resolvido, os seguintes passos serão seguidos:
1. Estudo e planejamento da implementação da estratégia escolhida.
2. Implementação, desenvolvimento e modificação dos contratos para atender as especificações.
3. Desenvolvimento de uma interface web.

The issue names the existing DPublish contract, a new review contract, and a possible Python REST API or web interface, but no files or tests. Start by locating DPublish and its contract sources, then compare the two proposed storage strategies and define the review workflow. Done means authors can submit pre-prints for review and reviewers can list and evaluate pending manuscripts through the chosen interface.

Written by the indexing model from the issue text.