Definição de quais status das postagens serão usados

[Mateusas3s]

Definição de quais status serão usados

Descrição:

Na comunicação entre a aplicação da comunidade acadêmica e a de gestão é necessário definir os status da postagem/denúncia. Quais serão ela?

A priori temos:

• Aguardando aceitação
• Em andamento
• Resolvido

Tarefas:

Checklist de ações que devem ser realizadas.

• [x] Definir rotulação do status

Critérios de aceitação:

Descrever os requisitos necessários para que a issue possar ser finalizada.

• [x] Status serem validados por ambos os times

[Bruno-Felix]

Acredito que esses 3 estados pré levantados é o mínimo necessário para cobrir bem o processo de solução de uma postagem.

Talvez o usuário não precise de mais informações para se sentir atualizado sobre o andamento da solução.

[Mateusas3s]

estavamos pensando em colocar além do status de "aguardando aceitação", pro caso da postagem ainda não ter sido validada com real, o status de "aceito" depois dela ser validada como um problema real. Depois disso ela entraria como "em andamento" quando se inicasse o processo de resolução E resolvido no final, o que tu acha?

[Mateusas3s]

Outro tipo de status que seria interessante ter é o de "arquivado" ou o de "não aceito", uma vez que pode ter uma postagem falsa. daí quando o gestor validar que a postagem é falsa ou de alguma forma inválida ele atualiza o status e vcs recem isso e daí vcs tratam excluindo o post do feed ou notificando no próprio post que ele é inválido

[Bruno-Felix]

estavamos pensando em colocar além do status de "aguardando aceitação", pro caso da postagem ainda não ter sido validada com real, o status de "aceito" depois dela ser validada como um problema real. Depois disso ela entraria como "em andamento" quando se inciasse o processo de resolução E resolvido no final, o que tu acha?

Existem certos pontos a serem pensados sobre a visualização desses status.

Uma pessoa que fez uma postagem sobre abuso, por exemplo, não seria interessante ver sua postagem recebendo um status de aguardando aceitação.

Talvez o caso de não ter sido aceito seja interessante. Mas ai pensamos em excluir essa postagem e gerar uma notificação de exclusão por ser aceita, ou seja, o usuário não veria mais essa status.

[Mateusas3s]

a questão de visualizar o status é simples, é só criar uma condição no código para não mostrar certo status caso a o user seja anônimo.

e no caso do "não aceito" a principal função dele nem é a visualização mas vcs automatizarem a exclusão do post se for o que vcs decidirem. No momento que o Gestor alterar o status para "não aceito" o post já é excluido no feed da comunidade e no lugar do post é gerado uma notificação que ele foi excluido

estavamos pensando em colocar além do status de "aguardando aceitação", pro caso da postagem ainda não ter sido validada com real, o status de "aceito" depois dela ser validada como um problema real. Depois disso ela entraria como "em andamento" quando se inciasse o processo de resolução E resolvido no final, o que tu acha?

Existem certos pontos a serem pensados sobre a visualização desses status.

Uma pessoa que fez uma postagem sobre abuso, por exemplo, não seria interessante ver sua postagem recebendo um status de aguardando aceitação.

Talvez o caso de não ter sido aceito seja interessante. Mas ai pensamos em excluir essa postagem e gerar uma notificação de exclusão por ser aceita, ou seja, o usuário não veria mais essa status.

[Mateusas3s]

sobre o status, vi que na modelagem vcs colocaram como inteiro, acho que seria melhor deixar como string, ou fixar os ids como: 1 - em análise; 2 - aceito; 3 - não aceito; 4 - em andamento; 5 - concluído

minha sugestão é deixar com string ou varchar, o que vocês acham?

[DanielPortods]

Na concepção de organização da nossa frente de desenvolvimento, optamos em mostrar apenas 3 fases de status de um registro: 1 - Aguardando, 2 - Em andamento e 3 - Resolvido. Cabendo uma quarta: 4 - Arquivado.

Status 1 - Aguardando: Esse estágio já abrangeria todo o processo do gestor de visuazilar e validar a problemátíca. Caso verificada a suposta improcedência do problema pelo gestor, o registro deverá tomar o status 3 - resolvido. isso fará o regitro passar pelo tempo de feedback da comunidade explicado mais a frente.

Status 2 - Em andamento: Validada a problemática, essa fase indicaria que o gestor já está ciente do problema e está trabalhando em resolvê-lo.

Status 3 - Rosolvido: Nessa fase, é da ideia do gestor que o problema foi resolvido com sucesso. Porém, podem ter discordâncias sobre a resolução. Sendo assim, achamos que o registro nesse estágio deverá ficar por algum tempo (2 semanas a 1 mês) no feed com o staus resolvido. Isso permitiria os usuáris visualizarem o que foi feito e dar um feedback sobre a resolução na postagem. Daí caberia ao gestor analisar o feedback da comunidade e recomeçar o status da postagem para o 1 ou o 2. Terminado o tempo de feedback, o registro sairia do feed e ficaria disponível apenas para o autor em seu perfil.

4 - Arquivado: Esse status, serviria apenas pra comunicar pro sistema que o registro foi autuado como falso ou impróprio. O que faria a exclusão do registro e, se cabível, aplicação de punição ao autor.

É importante lembrar que, no caso de registro anônimo, todos os registros vão passar por curadoria da gestão, podendo ser ou não postados (caso o usuário não autorize o registro não será postado, caso autorize o gestor terá a ultima avaliação se cabe a postagem ou não (devemos pensar em como ocorrerá essa comunicação)). Além disso o engajamento da comunidade, será fator de pressão e cobrança para o avanço nos estatus da postagem não sendo exclusivo para alguma fase.

Sobre o tipo de dado a ser usado, não vejo problema em ser string.

[Mateusas3s]

OK, vou validar aqui com o pessoal a resposta de vocês e já dou o feedback

[Mateusas3s]

Tudo Ok Pessoal!!!