Skip to content
This repository has been archived by the owner on Sep 26, 2024. It is now read-only.

Revalidar municípios com mais de 100 mil habitantes // Revalidate all municipalities above 100k inhabitants #38

Closed
bcbernardo opened this issue Dec 23, 2020 · 2 comments
Labels
validation Issues related to the process of peer-reviewing submited registries

Comments

@bcbernardo
Copy link
Collaborator

Em português

Um dos pontos que voltamos a conversar nessa reunião [17/12/2020] foi sobre a revalidação das cidades. Na última reunião de quinta havíamos conversado sobre padronizar os critérios para validação e revisitar todas as cidades.
O que vocês acham sobre isso?
Devemos padronizar esses critérios e revalidar todas as cidades?

Por @cecivieira , no canal do Censo no Discord. Reproduzindo aqui para manter o registro público da discussão, argumentos e decisões.

In english

One of the topics we discussed again in this community meeting [Dec. 17, 2020] was the revalitation of registries for cities. In the last thursday meeting, we had talked about standardizing criteria for validation, and then double-checking all cities' registries.
What do you think about that?
Should we stantardize this criteria and then revalidate all cities?

By @cecivieira [freely translated], in the Census Discord channel. Posting here to keep a public record of the discussion, arguments and decisions.

@bcbernardo
Copy link
Collaborator Author

bcbernardo commented Dec 24, 2020

Em português

English version in a separated post below

Relatando discussões sobre este tema na reunião de 23/12/2020, com @bcbernardo, @cecivieira e @giuliocc .

A @cecivieira relatou os argumentos pró-revalidação: consistência metodológica na base atual e alinhamento com os futuros mapeamentos, no que se refere aos critérios de validação. O @bcbernardo (eu 🤓) questionou se as eventuais inconsistências se referiam aos campos presentes no formulário de validação (data inicial dos diários, formato, fontes) ou apenas aos campos de texto livre "Observações" e "Anomalias".

Sobre os campos "oficiais" do formulário, a percepção relatada foi de que os critérios foram construídos relativamente cedo na pesquisa - conforme os casos duvidosos iam aparecendo, e antes que fossem validados para entrar na base. Uma vez tomadas, evitou-se sempre rever essas decisões, para manter a consistência metodológica. E os critérios foram comunicados para as pessoas envolvidas no mapeamento, por meio do FAQ, e, principalmente, para as pessoas validadoras, por meio das reuniões semanais, das atas das reuniões e das respostas a dúvidas no Discord.

Algumas inconsistências eventuais são possíveis nos campos do formulário - especialmente, na identificação do formato de publicação de portais que disponibilizam mais de um formato para acesso. Neste caso específico, porém, é possível resolver a maior parte dos problemas verificando se há inconsistências de classificação do formato para municípios com o mesmo domínio de portal - afinal, a maioria desses casos ocorrem em portais com múltiplos municípios.

Quanto aos critérios eventualmente considerados nos campos "Observações" e "Anomalias", a proposta mais organizada que temos até agora é a da @JTrevine :

f) Observações:
Diário desmembrado*: [S ou N]
Link:

= *DO desmembrado: quando não há um diário oficial, mas o conteúdo de um diário normal é pulverizado em seções decretos/portarias/licitações pelo site da pref

ps.: precisa confirmar se oferece, mas não é necessário registrar > como < se confirmou que dado município não publica DO (se via LAI, envio de email, ligação, etc).

g) Anomalia obs:
recaptcha: [S ou N]
site fora do ar ou instável: [S ou N]
disponibilizado via nuvem (dropbox/drive): [S ou N]

A @cecivieira e o @giuliocc pontuaram que qualquer alteração para incorporar esses critérios como parte do mapeamento deveria passar por uma modificação do formulário e por uma revalidação o mais breve possível - uniformizando a base antes de mapearmos mais municípios com uma metodologia diferente. No entanto, considerando os critérios adicionais propostos até aqui, tendemos a considerar que não justificavam o trabalho de uma revalidação:

  • Site fora do ar ou instável: já está previsto como etapa da análise, a ser realizada de maneira automatizada (ver Medir o tempo em serviço dos portais // Measure portals' uptime #41)
  • Presença de Captcha: embora o ideal fosse ser um campo do formulário, para indicação durante o mapeamento, também é possível automatizar com a análise do HTML dos portais
  • Disponibilizado via nuvem (Dropbox/Drive...): não consideramos que seja um critério de alto interesse social
  • Diário "desmembrado": é aspecto técnico com alguma relevância para a modelagem dos dados no projeto Querido Diário, mas saber exatamente o percentual de diários nessa situação não gera um ganho muito maior para a tomada de decisão do uma simples estimativa de ordem de grandeza - que já temos com base na experiência do mapeamento. Além disso, sempre houve um critério bem delimitado de que esses municípios seriam mapeados como não tendo diário online.

Considerando esses argumentos, a tendência até aqui foi de sistematizar os critérios de validação já existentes (tarefa já prevista e necessária para o relatório e para facilitar o trabalho de futuras validadoras [ver #43]) e fazer apenas checagens pontuais na base (de consistência dos formatos de publicação para um mesmo domínio [ver #44]; e a revalidação dos municípios classificados como sem diário oficial [ver #37]). Não haveria uma revalidação ampla dos mais de 500 municípios já mapeados.

Por hora, esta issue continua aberta até que possamos discutir o assunto com mais pessoas presentes e ouvir os argumentos de quem é favorável à revalidação ampla.

@bcbernardo
Copy link
Collaborator Author

bcbernardo commented Dec 24, 2020

In English

Reporting the discussions on this issue held in the Dec. 23rd, 2020 community meeting, with @bcbernardo, @cecivieira and @giuliocc .

@cecivieira reported the arguments pro re-validation: methodological consistency within the current database, and alignment with future mappings, concerning validation criteria. @bcbernardo (myself 🤓) questioned whether the perceived inconsistencies referred to the fields in the validation form (initial date for the gazettes, publication format, sources) or only to the free text fields "Observations" and "Anomalies".

About the "official" (non-open text) form fields, the perception was that the relevant criteria were built relatively soon in the research - as dubious cases emerged, and before they were validated into the database. These decisions have not changed since they were initially taken, in order to maintain methodological consistency. And the criteria were communicated to people engaged in the Census, through the FAQ, through the weekly community meetings and their written records, and through answers to individual doubts in Discord.

Some inconsistencies are still possible in the form fields, anyway - specially, in the classification of the publishing format, when the portal offers multiple formats for access/download. In this specific case, however, it is possible to solve most of the problems by verifying if there are inconsistencies in the classification across the same URL domains in the database - after all, most of these cases occurred in portals with multiple gazettes.

In what concerns to the open text fields "Observations" and "Anomalies", the most well organized proposal we have so far is the @JTrevine's one [freely translated]:

f) Observations:
Broken down gazette*: [S ou N]
Link:

= *Broken down gazettes: when there is no proper official gazette, but the official acts are published individually in sections/executive orders/ordinances/procurements in the city hall website

ps.: we should confirm it there is a official gazette, but there is no need to registry by which means this confirmation was archived (wheter by FOIA requests, sending emails, phone calls and so on).

g) Anomalies:
recaptcha: [Y or N]
website temporarily down or unstable: [Y or N]
published through cloud services (dropbox/drive): [Y or N]

@cecivieira and @giuliocc pointed that any change to incorporate these criteria as a permanent part of the Census should imply a modification of the form and a re-validation as soon as possible - standardizing the database before we map more municipalities using a different methodology. However, considering the additional criteria proposed so far, we did not feel as they justified the effort of a re-validation:

  • Website temporarily down or unstable: this criteria was already envisaged as a part of the analysis stage, to be automated (see Medir o tempo em serviço dos portais // Measure portals' uptime #41)
  • Captcha presence: while this could be ideally a checkbox in the mapping form, it is also possible to automate it by checking the portals HTML source codes
  • Published through cloud services (Dropbox/Drive...): we did not feel this as a criteria of high social interest
  • "Broken down" gazettes: this is a technicality of some importance to data modelling in Querido Diário project as a whole, but knowing precisely the percent of gazettes in this situation generates no significant gain for decision making over a simple order of magnitude estimating - that we already have from our experience mapping and validating the records. Besides, there was always a well delimited criteria that these municipalities should be mapped as not having their gazettes online.

Considering these points, the tendency so far is to systematize the existing validation criteria (a task that was already needed for the Report, and for helping future validators [see #43]) and to make only specific checks in the database (searching for inconsistencies in the publication format for the same domains [see #44]; and re-validating the municipalities classified as having no gazette online [see #37]). There would not be a broad re-validation of the more than 500 municipalities already mapped.

For now, this issue remains open until we can discuss it with more people present and hear the arguments pro broad re-validation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
validation Issues related to the process of peer-reviewing submited registries
Projects
None yet
Development

No branches or pull requests

1 participant