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.

[waldyrious]

Outro exemplo que podia ser útil aqui é a UI do sistema de revisão de sugestões de edição do StackOverflow, que permite ver as avaliações individuais, e até sua justificação. Por exemplo, nesta edit, pode-se ver como os três reviewers votaram, e até as estatísticas dos intervenientes, o que ajuda a interpretar o estado final/agregado:

Claro, isto parece confuso visto tudo de uma vez, mas no nosso caso só há dois intervenientes em vez de 4, pelo que a informação pode ser mostrada de forma mais compacta; e de notar que a segunda caixa, com as estatísticas, só é exibida quando se clica no botão "reviewer stats" da primeira caixa, ou seja, é usado o padrão de progressive disclosure que torna a informação mais fácil de consumir, o que certamente deveríamos usar também.

Acho que algo deste género (mais simplificado, claro) seria definitivamente preferível a estar a montar um sistema de arbitragem/mediação.

[jfoclpf]

Caros, muito obrigados pelo retorno e pelos comentários

1) Evitar que várias pessoas submetam a mesma ocorrência

Para isso sugiro colocar no mapa do formulário de submissão de ocorrência, as ocorrências que já existem e que estão por resolver. O mapa do formulário mostra sempre a zona onde o utilizador se encontra e por isso verá as ocorrências existentes nas redondezas. O utilizador poderá vê-las e clicar num botão "Também quero reportar esta ocorrência", adicionando fotos se quiser. Que te parece @luisjfvieira e @worm69 ?

Neste caso precisaria de adicionar um campo à tabela da BD, para contemplar utilizadores adicionais para a mesma ocorrência.

2) Tentativa de trolling, utilizador que desaparece, etc.

@luisjfvieira exigir trabalho de moderadores não é solução a longo prazo, o sistema precisa de ser o mais autónomo quanto possível. No futuro, como sugere o @worm69 podemos implementar algoritmos para detectar trolling e abusos, mas para já não é prioritário nesta fase. Sugiro implementar a sugestão do @waldyrious , ou seja, em cada ocorrência saber se o município, freguesia e cidadão, cada um deles, colocaram o item como resolvido.

A ocorrência apenas estaria completamente resolvida quando o cidadão marcasse como resolvida, ou quando, se não respondesse, tivesse decorrido 15 dias desde a data em que o município marca como resolvido. Que te parece @waldyrious ?

[waldyrious]

A ocorrência apenas estaria completamente resolvida quando o cidadão marcasse como resolvida, ou quando, se não respondesse, tivesse decorrido 15 dias desde a data em que o município marca como resolvido. Que te parece @waldyrious ?

Honestamente, não me agrada muito que a resolução fique confirmada simplesmente por não resposta do cidadão, o que pode acontecer por várias causas, mas entendo que seja a solução mais simples. Eu só insistiria em dois pontos:

1. Deve ficar explícito que o cidadão não confirmou e que a situação considera-se resolvida apenas por omissão (por exemplo, com iconografia de double checks ✔️✔️ como eu sugeri acima, ou algo semelhante);
2. Devia ser possível ao cidadão responder mesmo depois dos 15 dias passados, o que mudaria o estado da ocorrência novamente para "não resolvida".

[jfoclpf]

Olá @waldyrious

1. Sim, isso ficará claro na ocorrência com esses checks
2. Sim, o cidadão poderá sempre marcar a ocorrência como não resolvida, na APP

[jfoclpf]

Adicionar campos à tabela da base de dados SQL, para poder contemplar estas novas funcionalidades.

Neste momento a tabela tem estes campos

Precisamos de adicionar os seguintes campos

• nome_op (nome do original poster)
• email_op (email do original poster)
• utilizadores_adicionais (text string, JSON array com users adicionais {nome, email, device_uuid}, que referem que tal ocorrência também lhes diz respeito)
• ocorrencia_resolvida_por_op (boolean)
• ocorrencia_resolvida_por_municipio (boolean)
• ocorrencia_resolvida_por_freguesia (boolean)
• ocorrencia_resolvida_por_utilizadores_adicionais (text string, JSON array com users adicionais {nome, email, device_uuid}, que referem que tal ocorrência está resolvida)

[jfoclpf]

Estive 3 noites a programar :)

Neste momento o email gerado já gera dois URLs, um para o município dar a ocorrência como resolvida e o outro para a freguesia dar a ocorrência como resolvida. Falta apenas notificar o OP com o email.

Agora a ocorrência fica assim: https://nomeubairro.app/ocorrencia/?uuid=35a01022-3568-48ad-8041-e1b7d98a26b3

Que vos parece?

[waldyrious]

Promissor! Mas gostava de ver como ficaria com um estado intermédio, por exemplo o município a dar como resolvida e o cidadão não. O campo "Ocorrência resolvida" passaria de "Não" para "Sim", ou outro valor?

Além disso, acho que seria bom apenas mostrar o campo relevante para a entidade que recebe a ocorrência, assumindo que apenas a freguesia ou apenas o município recebe a comunicação; se esta assunção estiver errada, faz sentido ficar como está, naturalmente.

Finalmente, tenho uma sugestão para simplificar a leitura dos dados, marcando os três estados como sub-estados do principal. Por exemplo, algo deste género:

Isso pode-se implementar apenas modificando o HTML e CSS da seguinte forma:

<details><summary><b>Ocorrência resolvida</b>: Não</summary>
    <b>Declarada como resolvida pelo cidadão que reportou</b>: Não<br>
    <b>Declarada como resolvida pelo município</b>: Não<br>
    <b>Declarada como resolvida pela freguesia</b>: Não<br>
  </details>  

details summary ~ b { padding-left: 2em; }
details { margin-bottom: 1em; }

WDYT?

[jfoclpf]

Olá @waldyrious , obrigado pelos comentários

Neste momento já tenho o servidor de email a funcionar mas não está implementado no código ainda, por isso neste momento a ocorrência está resolvida apenas quando o OP a marca como resolvida. Depois seguirá o fluxograma já posto ali em cima:

Sugeres modificações a este fluxograma? @worm69 este fluxograma parece-te bem?

Muito obrigado pelas tuas sugestões em relação aos detalhes, já foi feito com 6e5638a
ora vê: https://nomeubairro.app/ocorrencia/?uuid=35a01022-3568-48ad-8041-e1b7d98a26b3

[jfoclpf]

@worm69 @luisjfvieira @enieber @bastiao @RobinSapo

concordam com este fluxograma? Sugerem alguma alteração?

[waldyrious]

Desculpa, realmente isso já tinha sido discutido e acordado acima. Não tenho nada a apontar sobre o fluxograma, a não ser talvez acrescentar um asterisco no "Sim" quando a ocorrência é resolvida por não resposta do cidadão.

Quanto ao uso do elemento <details>, obrigado pela rápida implementação :)

[bastiao]

@worm69 @luisjfvieira @enieber @bastiao @RobinSapo

concordam com este fluxograma? Sugerem alguma alteração?

Acho que está muito bom!

Eu vejo algumas vantagens no município ou freguesia receber também uma notificação/e-mail, caso o cidadão marque a ocorrência como resolvida. Por exemplo, no caso da Freguesia ela muitas das vezes funciona de 'broker' entre organizações responsáveis. Recebe reclamação e reporta a outra entidade (sem grande seguimento posterior, infelizmente). Uma desvantagem disso é que com larga utilização isso pode ser interpretado como 'spam' pelos operacionais (responsáveis das Freguesias). Deixo à vossa consideração.

[jfoclpf]

boas @bastiao
se reparares bem no fluxograma, quando o cidadão declara a ocorrência como resolvida, o município e/ou freguesia são alertados por email

[bastiao]

boas @bastiao

se reparares bem no fluxograma, quando o cidadão declara a ocorrência como resolvida, o município e/ou freguesia são alertados por email

Eu sei, apenas levantei algumas vantagens e desvantagens :)
Por exemplo, eu não sei se a possibilidade de receber um e-mail semanal com dados agregados não seria mais vantajoso no caso das Freguesias (recursos mais limitados e menos tempo para análises caso a caso). No entanto, acho que está muito bom, e podes ir tendo feedback com a utilização.

[jfoclpf]

@bastiao e @waldyrious que vos parece para já termos também URLs com listas de ocorrências para cada freguesia ou município?

Por exemplo, a ligação https://nomeubairro.app/freguesia/Santa Maria Maior (Lisboa) dar uma lista de todas as ocorrências dessa freguesia

[waldyrious]

@jfoclpf Acho excelente! Também seria ótimo se se pudesse filtrar o mapa de anomalia por distrito, município e freguesia (semelhante ao que se pode fazer, por exemplo, no mapa de resultados das eleições). No entanto, esta funcionalidade deveria ser tratada num issue à parte, para não poluir esta thread. Se gostares da ideia, eu abro o issue com algumas sugestões para essa funcionalidade :)

Um pequeno issue: ao navegar para https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa), sou redirecionado para https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa (sem o parêntese no fim) e isso dá um 404. Podes verificar o que se passa?

[jfoclpf]

@waldyrious gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.

Dá página não encontrada porque o caminho /freguesia ainda não está implementado, queria apenas saber qual a vossa opinião a propósito. Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.

[bastiao]

@waldyrious gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.

Dá página não encontrada porque o caminho /freguesia ainda não está implementado, queria apenas saber qual a vossa opinião a propósito. Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.

Parece excelente ideia!

[waldyrious]

gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.

Will do!

Dá página não encontrada porque o caminho /freguesia ainda não está implementado

Ah! Sorry, realmente li mal. Mas ainda assim, acho estranho o redirect a remover o ) no final do link. Não seria expectável o próprio URL https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa) dar um 404?

Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.

SGTM!

[jfoclpf]

Tens razão @waldyrious , de facto é estranho o redirect remover o ) no final, mas eu vejo isso melhor quando implementar os caminhos.

Na realidade como o Wordpress usa PHP e tem uma estrutura menos flexível para os caminhos, terei de ter um caminho único /ocorrencias (no plural) e depois filtrar com "query parameters", por exemplo /ocorrências?freguesia=Santa%20Maria%20Maior&municipio=Lisboa ou /ocorrências?municipio=Évora.

Que te parece @waldyrious ?

[waldyrious]

Sounds good! Acho que funciona igualmente bem.

[jfoclpf]

parece-vos bem @waldyrious e @bastiao ?
https://nomeubairro.app/ocorrencias
https://nomeubairro.app/ocorrencias/?municipio=Lisboa&freguesia=Lumiar

[jfoclpf]

adicionar campo de email aqui