okfn-brasil / euvoto Goto Github PK

É uma sugestão que requer mais discussão para ser conceitualmente validada/apreciada, e que talvez, mesmo validada, seja mais trabalhosa de ser implementada.

Nessa versão beta, onde a comunidade já está postando comentários bacanas nas votações, um tipo de comentário muito frenquente foi algo como "... mas o texto da norma precisaria ser revisado..." ou "aprovaria se o texto fosse revisado".

Uma quarta opção de voto, além do SIM/NÃO/ABSTENÇÃO, daria margem para atender às pessoas que fizeram esse tipo de comentário.

PS: estou chamando de "SIM condicionado", mas pode ser qualquer outro nome.

Veja reclamações em

https://twitter.com/ewout/status/619167214164406272

Um importante resultado dessa versão beta do EuVoto já pode ser notado: não ia ficar bom misturar no mesmo site universos de interesse muito distintos, em particular as esferas Estadual e Federal: apesar de serem complementares para a municipal, dissipariam o escopo... Analogamente ter um volume muito grande de projetos de lei no site, pode poluir e dificultar o destaque que se espera dar aos temas mais populares/relevantes.

Fica a sugestão de criar um clone http://euvoto.org/FEDERAL

Em toda comunidade git são entendidos como auto-evidentes labels tais como "bug" ou "enhancement", que são coisas para a "to do list" da equipe. Já issues de "de comunicação com a comunidade" recebem labels mais diversos...

Essas duas finalidades são bem distintas e sinalizam para a esquipe do projeto comportamentos bem distintos. Por serem "sinalizações" os labels do projeto acabam compondo um pequeno vocabulário, que pede um "glossário"... É importante que todos da equipe e e todos da comunidade façam uso das mesmas convenções, ou seja, que esse glossário esteja definido em algum lugar, garantindo o uso consistente dos labels... Como ainda não existe na OKBr uma sugestão para isso, pode-se adotar os labels do projeto-pai: DemocracyOS/app/labels (reparar no uso consistente, todos com mais de zero issues).

Independente da convenção adotada, sempre é possível entender as issues, e portanto os seus labels, como itens de dois grandes grupos:

• Lista de tarefas da equipe (to-do-list): tipicamente issues aprovadas pela coordenação do projeto para que entrem na fila de trabalho da equipe de desenvolvimento. A equipe precisa ler/conhecer essas issues para poder discutir a agenda do projeto.
• Comunicação: todo o resto, que garante uma comunidade participativa e o bom acolhimento de potenciais colaboradores (!). Apesar de poderem surgir coisas interessantes, a equipe não precisa ler/conhecer essas issues. Pode-se esperar inclusive respostas/debates de pessoas que não são membros da equipe de desenvolvimento (ex. zelador ou outros membros da OKBr). Exemplos:
  • Aparentes bugs que são na verdade decorrentes de mal-uso (ex. não seguir o manual ou mensagens da interface). Em geral são fechados rapidamente, mas são bem-vindos, merecem resposta/diálogo pois a recorrência será indicativo, por exemplo, de falha da interface.
  • Duvidas: dúvida da comunidade de usuários ou mesmo "navegantes curiosos". Ver exemplos no label question.
  • Novas funções para um futuro distante: quando a sugestão faz sentido, pode ficar registrada como numa lista de e-mails, gerando mais comunicação, não precisa ser fechada. No final, os encarregados do business plan dos "investimentos futuros" poderão apreciar, fechando com um parecer mais amigável sobre o uso da ideia.
  • Discussões: solicitações de "conversa com o projeto", as mais variadas. Ver exemplos no label discussion.

NOTA: issues ainda não-rotuladas são aquelas a equipe não precisa perder tempo lendo.

O acolhimento aos colaborares é um valor da OKBr a ser preservado nos projetos-OKBr... Se o projeto está ativo, existem coordenador e zelador do projeto, portanto existem recursos para lidar com esse "custo de comunicação".

Sobre os papeis do zelador e do coordenador:

• O coordenador é a autoridade maior do projeto, inclusive no relacionamento com a comunidade. Cabe ao coordenador definir a to-do-list e intervir nas demais issues quando julgar necessário, em particular o fechamento da issue.
• O zelador não deixa de ser um colaborador, podendo ajudar a gerenciar/mediar a comunicação com a comunidade... Por isso é importante que o zelador tenha direito de rotular issues (o quanto antes para não tomar tempo do coordenador) como
  discussion (ou "far future") ou question, ou memso declined.

Suposições sobre os objetivos do Github/issues.
Os objetivos das issues em um projeto aberto à interação com a comunidade e à colaboração, são mais amplos que issue tracking system em contexto empresarial, por isso foram agrupados em to-do-list e comunicação.

O LexML é muito mais do que um "site de busca",

o Projeto LexML, http://projeto.lexml.gov.br/ , definiu uma série de padrões para interoperabilidade

sendo talvez o padrão mais importante, aquele que define a URN LEX para todas as normas e proposições normativas (projetos de Lei) do Brasil.

• Toda Lei, e seu Projeto de Lei, tem um identificador universal e único. Por exemplo o Marco Civil da Intenet, tem um identificador único, urn:lex:br:federal:lei:2014-04-23;12965, assim como o Projeto de Lei que lhe deu origem, o urn:lex:br:senado.federal:projeto.lei;pls:2000-05-24;151
• Toda URN LEX-BR pode ser resolvida no http://www.lexml.gov.br/urn , e esse URN Resolver tem garantia de estabilidade (não falha nem sai do ar) e de persistência (em 2020 ainda vai estar resolvendo as URNs) ... Análogo do http://dx.doi.org.

Hoje, se fossemos fazer um clone do EuVoto para leis federais já disporíamos de um acervo de mais de 63mil proposições!

Uma ferramenta simples, complementar ao EuVoto, poderia ajudar o usuário a buscar projetos de lei desejados no LexML (vide cesta), retornando as suas URNs. Também de forma simples, a criação de "boxes preliminares de projeto de lei" poderia ser automatizada com uso dos metadados da Lei oferecidos pelo padrão LexML.

São apenas ideias e exemplos ilustrativos dos ganhos (de interoperabilidade e outros) no uso de padrões LexML, já vigentes e amplamente suportados.

Outros links LexML:

• http://projeto.lexml.gov.br/documentacao/destaques-lexml#o-que-lexml
• https://pt.wikipedia.org/wiki/LexML_Brasil

Ao que tudo indica a adaptação do DemocracyOS que está rodando no EuVoto comporta "prazo para votar", ou seja, uma fase do processo onde o "placar" da votação fica escondido, para evitar efeitos de indução.

Como está em fase beta e as pessoas ainda querem sentir e discutir as opções, os mecanismos alternativos, seria interessante que, ao longo do ano, sempre tivesse um ou outro projeto de lei em "período de votação com placar fechado".

PS: como todos precisam fazer cadastro, pode até ser uma desculpa para gerar mais movimento, com malas-diretas (emails) do tipo "fechamos a apuração, venha ver o resultado da sua votação do mês passado!".

Sobre o README.md. Uma apresentação para o público do projeto (falantes do português) é importante para que esse mesmo público participe nas issues, e entenda as relações (transparência) entre o site euvoto.org e o seu desenvolvimento.

Sugere-se uma pequena apresentação em portugues e, minimamente, os links

http://euvoto.org/
http://wiki.okfn.org/Open_Knowledge_Brasil/Eu_Voto

PS: um texto de sinopse produzido para o README também poderia ser usado em http://br.okfn.org/projetos/ (que carece de uma chamada EuVoto atualmente), ou vice-versa.

Olá, há um indicativo de retomar o projeto e, principalmente, replicar em outros municípios.

Para tanto precisamos estimar o "custo" (horas e tarefas) de upgrade... Por ter havido customização do design, imagino duas frentes:

1. Aproveitando exatamente este mesmo git, tentar atualizar apenas o Bootstrap, da versão aqui utilizada v3.2 para a mais recente, de 2016, v3.3.7. Se isso não causar impacto ótimo, senão avaliar o custo de ajuste.

2. O core de DemocracyOS que está em uso teve a sua ultima atualização em março de 2015... De lá para cá houveram diversas atualizações... Acaba de ser lançada a versão 2.6.3, fica a sugestão de adotarmos para esse final de 2017 a versão 2.6.
   Se for tranquilo um simples git pull, ótimo, o custo será mínimo... Mas provavelmente o menos trabalhoso será trazer um clone e então adaptar o antigo design nele.

Outras demandas que podem surgir ou se tornar interessantes com a replicação em mais municípios:

• uso de Docker (extension) no lugar de instalação direta.

• Colaborar com a tradução pt-BR direto no core bin/dos-translate, etc.

• Estudar possibilidade de "template temático" para ajuste básico de cores, nome e logo do município.

Na reunião OKBr de 2015-04-07 (ontem) surgiu o comentário de que "votos do EuVoto podem ser o mesmo grau de responsabilidade que um voto like do Facebook"...

Todos concordam: mesmo com login (que já afugenta uma parcela do público) e com uma comunidade em torno fazendo comentários sérios e convidando gente para "votar consciente", etc. acaba virando um like... É de fato um dos grandes dilemas para qualquer sistema desse tipo: quando tudo fica muito fácil, simples e livre, sem consequência sensível, fica também com aura de menos relevante...

... Uma solução, bastante discutível, mas que demonstrou ter muitos adeptos durante a discussão, é o "voto pago". Justamente, posto assim é até contraditório com o conceito de democracia e "abertura"... Mas usando um termo mais ameno, "contribuição/doação para o projeto de lei", fica mais evidente o viés solidário e democrático. Como em computação gostam de caricaturas que evidenciam a função do rótulo ("abort", "run", "finger", "die", etc.) vou manter o jargão auto-evidente:

• voto-displicente: sem login (no máximo conferindo IP ou session para não repetir)... Mesmo assim ninguém leva a sério, pode até comprometer a credibilidade do site: está aqui só para expressar o conceito e o fato de haver uma gradação de responsabilidades.
• voto-like: normal (em uso no EuVoto), aquele que não requer maior responsabilidade/compromisso do que fazer login.
• voto-pago: aquele que, mesmo sendo 0,01 Bitcoin (ou R$1), faz o usuário pensar e expressar valor, e efetuar um ato formal (a transferência monetária). PS: requer login, e, quando moeda virtual, pode iniciar com um pequeno saldo de brinde (ver conceito de "carteira" abaixo).

Outras ideias que surgiram na discussão (tentando expressar e consolidar):

• contadores totalmente independentes: cada contexto (voto-like e voto-pago) tem o seu contador e o seu "placar"... Enfim, talvez precise de muita discussão antes de se tornar uma "issue" para o software, com requisitos mais objetivos.
• variantes de voto-pago: uma-pessoa-um-voto é a tradição, um-real-um-voto uma tradução direta, mas pode-se imaginar variações, tais como "valor livre" (votar 100 reais ao invés de 1)... A tradução de valor em voto pode requerer um tradutor mais sofisticado (tipicamente a raiz quadrada)... é outra longa discussão.
• fundo de promoção dos mais votados: os projetos de lei podem receber apoio operacional do EuVoto de diversas formas... A mais simples é o crowdfunding para fazer bons filmes no Youtube, visto que ter equipe de designers ou editores de filme, etc. no EuVoto requer recursos.
• carteira do site: o usuário doa (crowdfunding de micro-crédito) um valor ao EuVoto, mas não libera o valor, exceto se votar (voto com valor fixo ou montante livre) num projeto de lei. Independente de ser moeda virtual, um pequeno saldo de presente para o usuário recém-cadastrado pode ser um grande atrativo ("pega gosto" e continua mantendo a carteira cheia).

PS: dezenas de outras ferramentas de comunidade possuem "voto estilo like", talvez a mais popular, entre as mais "sérias" seja o Stackoverflow (askbot).