You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Levando em conta os protótipos de implementação Dpublish (para os contratos) e DAPH_API (Frontend e Backend em Python), escolhi desenvolver o contrato de publicação e a API para submissão de manuscritos, bem como um front-end associado a essa tarefa.
O desenvolvimento dessa proposta envolve 4 atividades (em ordem de prioridade):
Adaptação do contrato DPublish.
Possíveis adaptações ao protótipo da API disponibilizada.
Iteração contrato/API.
Desenvolvimento de um frontend apropriado para submissão de artigos.
Estratégia
Para o desenvolvimento dessa proposta é necessário antes de tudo ter um contrato de publicação apropriado. No momento, o contrato conta com um mapping entre o id/local do manuscrito e endereço da carteira do autor, o que é esperado. Entretanto, como descrito no artigo na seção Manuscript submission é necessário também que uma vez que uma vez que o autor tenha submetido o seu trabalho, esse manuscrito entre no estado de preprint, desse modo, é necessário também que haja uma associação entre o id e o estado do manuscrito (aguardando revisão, revisão 1, ...), no contrato.
Outros atributos podem vir a ser necessários a medida que os outros processos forem sendo desenvolvidos.
Com relação a API algumas poucas mudanças pontuais ao protótipo parecem ser necessárias.
Com relação ao modelo associado, muito pouco parece precisar ser modificado, visto esse já conta com entidades de autor, manuscrito e artigo, bem como campos apropriados.
A API deverá iteragir (fazer chamadas de submissão, por exemplo) com o contrato de publicação, isso será feito utilizando a biblioteca web3.py.
Com relação ao front-end, ainda não decidi como irei desenvolver (usando frameworks, ou não).
A medida que possível serão criados testes para avaliar a corretude de cada sub-atividade.
Requisitos
Durante esse processo certamente haverá comunicação com pessoas que estejam desenvolvendo atividades relacionadas, como a revisão, por exemplo.
Em particular esse processo tem como requisitos os protótipos do contrato de publicação e da API já disponibilizada.
Além disso, acredito que alguns requisitos surgirão à medida em que essa task seja desenvolvida, podendo ser incorporados no meu trabalho.
Cronograma
A minha ideia é desenvolver as sub-atividades (descritas na introdução) que não possuam dependências em ordem, até que todas sejam feitas.
The text was updated successfully, but these errors were encountered:
Introdução
Levando em conta os protótipos de implementação Dpublish (para os contratos) e DAPH_API (Frontend e Backend em Python), escolhi desenvolver o contrato de publicação e a API para submissão de manuscritos, bem como um front-end associado a essa tarefa.
O desenvolvimento dessa proposta envolve 4 atividades (em ordem de prioridade):
Estratégia
Para o desenvolvimento dessa proposta é necessário antes de tudo ter um contrato de publicação apropriado. No momento, o contrato conta com um mapping entre o id/local do manuscrito e endereço da carteira do autor, o que é esperado. Entretanto, como descrito no artigo na seção Manuscript submission é necessário também que uma vez que uma vez que o autor tenha submetido o seu trabalho, esse manuscrito entre no estado de preprint, desse modo, é necessário também que haja uma associação entre o id e o estado do manuscrito (aguardando revisão, revisão 1, ...), no contrato.
Outros atributos podem vir a ser necessários a medida que os outros processos forem sendo desenvolvidos.
Com relação a API algumas poucas mudanças pontuais ao protótipo parecem ser necessárias.
Com relação ao modelo associado, muito pouco parece precisar ser modificado, visto esse já conta com entidades de autor, manuscrito e artigo, bem como campos apropriados.
A API deverá iteragir (fazer chamadas de submissão, por exemplo) com o contrato de publicação, isso será feito utilizando a biblioteca web3.py.
Com relação ao front-end, ainda não decidi como irei desenvolver (usando frameworks, ou não).
A medida que possível serão criados testes para avaliar a corretude de cada sub-atividade.
Requisitos
Durante esse processo certamente haverá comunicação com pessoas que estejam desenvolvendo atividades relacionadas, como a revisão, por exemplo.
Em particular esse processo tem como requisitos os protótipos do contrato de publicação e da API já disponibilizada.
Além disso, acredito que alguns requisitos surgirão à medida em que essa task seja desenvolvida, podendo ser incorporados no meu trabalho.
Cronograma
A minha ideia é desenvolver as sub-atividades (descritas na introdução) que não possuam dependências em ordem, até que todas sejam feitas.
The text was updated successfully, but these errors were encountered: