Gestão das ocorrências, como e quem as marca como resolvidas

[RobinSapo]

Boas.

Como é que os municípios alteram o estado de uma reclamação, quando a situação está resolvida?

Obrigado.

[jfoclpf]

Tenho pensado nisso, mas contrariamente às outras APPs gosto que isso fique do lado do munícipe, ou seja, da pessoa que reporta. Neste momento apenas quem reportou pode dar a situação como resolvida.

Mas tenho pensado num sistema em que o município declara como resolvido e tal pede a confirmação ao munícipe, mas tal exige um serviço de email que ainda não está funcional.

Mas ficará o quanto antes. Está na todo list.

[bastiao]

Tenho pensado nisso, mas contrariamente às outras APPs gosto que isso fique do lado do munícipe, ou seja, da pessoa que reporta. Neste momento apenas quem reportou pode dar a situação como resolvida.

Mas tenho pensado num sistema em que o município declara como resolvido e tal pede a confirmação ao munícipe, mas tal exige um serviço de email que ainda não está funcional.

Mas ficará o quanto antes. Está na todo list.

Boa iniciativa!

Sugestão:
Penso que seja importante cada entidade (Municipio ou Junta de Freguesia) se conseguir associar a determinada área/território. A partir daí, poderia receber, por email, como sugerido, todas as novas ocorrências. Nesse email, poderia ter um link para a marcar como resolvida.

[jfoclpf]

@bastiao isso é possível, a questão é saber se deverá ser o município a dar a ocorrência como resolvida, ou deve ser o cidadão que reporta a ocorrência.

[bastiao]

Na minha opinião, deve ser possível para ambos. Assim, conseguem ter um serviço mais comunitário a funcionar, e contribuições dos municípios ou freguesias aderentes à plataforma. O ideal seria existir uma norma de software para fazer a gestão de ocorrências e garantir a interoperacionalidade. Na verdade, acho que estás ocorrências são ainda geridas de forma ad-hoc.

[enieber]

uma dica seria a separação do backend e uma api que o municipio possa se comunicar para marcar como resolverido.

[jfoclpf]

@enieber o backend já existe e está correr bem numa máquina Linux
https://github.com/jfoclpf/in-my-district/tree/main/server
é este backend que regista as ocorrências e que as coloca num mapa para todos verem
https://nomeubairro.app/mapa/

O que é preciso é um serviço de email e não tenho tido tempo para implementá-lo e nem sei se deva instalá-lo eu na máquina backend ou delegar para outros servidores, o que acarretaria um custo adicional, que não é comportável com um serviço gratuito, sem publicidade e open source.

@bastiao bem visto, na realidade imaginava simplesmente a freguesia ou município simplesmente receber uma notificação por email e dá-la como resolvida com um link

[jfoclpf]

Caros, após 2 dias de volta disto, o servidor de email local já está funcional, agora precisamos de decidir que modelo queremos adotar.

Fiz este fluxograma e gostaria de saber a vossa opinião @bastiao @enieber @RobinSapo @worm69 @waldyrious

Alguns pontos:

• No email gerado que o município e/ou freguesia recebem vai um link para marcarem a ocorrência como resolvida
• O cidadão marca a ocorrência como resolvida apenas na APP (Menu->Histórico)

Que vos parece?

[enieber]

@jfoclpf acho que ficou bem simples o desenho e resolveria bem o problema..

[luisjfvieira]

Olá! Sim, concordo com o fluxograma e a perspetiva de "o cidadao é que confirma", visto que muitos municipios marcam coisas como resolvidas por causa das métricas. Contudo, penso que se poderia refletir nas situações em que:
i) Várias pessoas reportaram a mesma questão e poderão ter visões diferentes sobre o que é "resolvido"
ii) Tentativas individuais de trolling, em que individuos nunca deixam que a coisa assuma o status de resolvido.

Penso que para estas poderia ser interessante pensar nalgum sistema de arbitragem. Faz-me pensar até nos mecanismos de fact-checking, em que não há verdades absolutas.

[worm69]

Olá! Sim, concordo com o fluxograma e a perspetiva de "o cidadao é que confirma", visto que muitos municipios marcam coisas como resolvidas por causa das métricas. Contudo, penso que se poderia refletir nas situações em que: i) Várias pessoas reportaram a mesma questão e poderão ter visões diferentes sobre o que é "resolvido" ii) Tentativas individuais de trolling, em que individuos nunca deixam que a coisa assuma o status de resolvido.

Penso que para estas poderia ser interessante pensar nalgum sistema de arbitragem. Faz-me pensar até nos mecanismos de fact-checking, em que não há verdades absolutas.

Boa visao critica @luisjfvieira.
Sobre teu primeiro ponto sugiro que se faça uma comparação simples de cada nova submissão com as existentes comparando se estão relativamente perto e o titulo. Um pouco parecido com o que o stackoverflow faz para as novas questões.
Sobre o segundo ponto podemos guardar quantas vezes a mesma submissão fez esse loop e por exemplo a terceira vez disparar um alerta para que um admin possa tentar validar melhor.

[waldyrious]

Acho que faz sentido que seja o cidadão que reportou o problema a ter a palavra final sobre a resolução. Mas há três casos em que a confirmação pode não acontecer:

1. O cidadão discorda da resolução
2. O cidadão não tem a oportunidade de confirmar (esqueceu-se do login, trocou de email, usou um email incorreto, o email da plataforma vai para o spam, o cidadão não dá importância à necessidade da confirmação, desde que o problema tenha ficado resolvido, etc.)
3. O cidadão deliberadamente não confirma por intenção maliciosa (trolling, vingança pelo atraso, whatever)

Sem estar a montar um sistema de intermediação/arbitragem, acho que a solução mais simples é expor precisamente a informação que existe de forma transparente e explícita, isto é, o estado das duas confirmações: a do município/freguesia, e a do cidadão.

A UX disto não tem que ser complexa: veja-se por exemplo os double-checks (✔️✔️) que vários sistemas de IM, como o WhatsApp, usam para indicar que uma mensagem foi enviada, recebida, ou lida.