Facebook likes e o significado de um voto online... Sugestão de discussão

[ppKrauss]

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).

[andresmrm]

Pessoalmente acho bastante ruim vincular dinheiro ao que deveria representar a
deliberação democrática.
Um dos meus medos é que pessoas com menos recursos acabem participando menos,
ou tendo menos peso do que as outras...

Mas talvez dar pontos limitados para cada pessoa votar pudesse ser uma
alternativa. Algo como o que você disse de dar um dinheiro inicial para cada
uma gastar, mas renovar isso mensalmente, por exemplo.
Logo cada pessoa teria de dar prioridade a um projeto ou outro, possivelmente
valorizando o voto.
Essa opção tem a vantagem de não ser tão complicada do ponto de vista técnico,
já que não envolve dinheiro.

Outra opção, que me agradou, foi a da Jonaya, das pessoas poderem doar para o
sistema, e esse dinheiro iria para as propostas mais votadas.
Assim o "poder de impacto" do sistema talvez dependa das doações, mas onde
esse poder é aplicado será escolhido mais democraticamente, sem obrigar
contribuições. (Poderia juntar com a opção anterior de ter votos limitados por
mês)
Porém essa opção ainda possui maior complexidade técnica, por envolver
dinheiro real.

[aivuk]

Desculpem, não querendo cortar a discussão mas já cortando, não acho que aqui seja o melhor local para esse tipo de discussão. Isso não é uma issue e valeria-se muito mais de uma discussão mais aberta (no sentido de não possuir uma barreira inicial tecnológica para a maior parte do público que pode se interessar pelo projeto mas não estar familiarizado com plataformas "too geeks" como o github), quem sabe na lista da okfn-brasil ou numa plataforma como http://discuss.okfn.org/?

[ppKrauss]

@aivuk,

Eu sugeri na lista que os zeladores façam o barulho e os coordenadores rotulem,

(...) Requer além da participação do público, uma certa gestão. O coordenador do projeto rotula (como "bug", "nova funcionalidade", "discussão", etc.) e o zelador do projeto ajuda a formatar e mediar as discussões.

Eu (e qq zelador) não tem permissão para criar labels, o máximo que posso fazer é o que fiz aqui, acrescentando no título da issue "sugestão de discussão": mesmo tendo fechado é importante dar seu label.

Quanto à ideia de levar de volta a discussão para a lista, ou fazer um fork para o discuss.okfn.org, creio que é algo a se discutir... Por hora concordo com o ultimo post na lista, do Ranieri, de que o importante é centralizar mais as discussões dos projetos... E por hora julgo que o melhor recurso para centralizar é o Github/issues.

[aivuk]

Você pode achar que seja melhor centralizar aqui, mas os desenvolvedores não concordam, ok? Fechei todas as issues que criou (exceto a de tradução do README) e já coloquei o label "invalid".

Antes de achar que o melhor pra você é criar aqui as discussões e cria-las, seria melhor antes consultar quem está trabalhando atualmente no projeto (Ariel e Edgar por exemplo) e baseado nisso decidir o que fazer.

Mas não leve muito a sério a minha reclamação, nada pessoal, todas as issues criadas por você achei muito importantes e gostaria de discuti-las, só não acho que como issue seja a melhor forma.

[ppKrauss]

@aivuk Ok, acho que você entendeu o ponto e a coisa já está sendo discutida neste momento na lista (okfn-br@lists.okfn.org)... Realmente é meio polêmico, achei que houvesse já certo consenso em usar as issues para tudo que fosse específico do projeto.

Eu sugiro aguardarmos os rumos da discussão na lista, talvez até numa reunião do Conselho (onde justamente vinham discutindo melhores estratégias de governança e comunicação nos projetos)... Uma semana portanto, para depois retomarmos aqui a discussão específica do EuVoto.

---

Pessoalmente eu acho que poderíamos "dar exemplo" (de bom uso das issues) e simplesmente rotular as issues: você, como coordenador, não precisa perder seu tempo com elas, apenas rotular e deixar que a comunidade decida quando fechar a discussão.

Seu foco e o da sua equipe (desenvolvimento) está nas issues rotuladas com bug e new issue (e variações do tema), apenas isso, pode ignorar todas as outras. Como é o coordenador quem rotula, não há risco de a comunidade te encher de trabalho que não era planejado.

[aivuk]

Seu foco e o da sua equipe (desenvolvimento) está nas issues rotuladas com bug e new issue (e variações do tema), apenas isso, pode ignorar todas as outras.

Nope, desculpe mas não é assim que funciona. Quem decide os labels e como o issue tracker será usada ainda será os membros que estão trabalhando ativamente no projeto. O feedback da comunidade é extremamente importante, mas não pode-se forçar uma dinâmica antes de consultar a equipe do projeto, ok?

[ppKrauss]

Hum... Acho que não "forcei" pois interpretei do Conselho (e posso ter errado redondamente nisso!) que se trata de uma diretiva... Como tudo hoje na OKBr aninda é muito informal, e a única diretiva que vi escrita foi a fazer-cracia, entendo que agi totalmente dentro das "constraints" correntes da OKBr :-)

Quanto ao uso dos labels, mais um problema de interpretação, e, sobretudo, de padronizar a linguagem... Acho que isso nunca foi feito, cada projeto adota a sua e a comunidade vai se adaptando... Talvez seja oportuno "padronizar" um pouco, buscar um consenso na lista talvez, sobre o uso de labels e o tipo concreto de sinalização que representarão para a comunidade OKBr.

[aivuk]

Eu só usei o termo "forçar" pois pensei que tinha criado outros issues após ter marcado esse como Invalid e comentado que não achava aqui a melhor forma de discutirmos. Se não foi isso o que aconteceu desconsidere o termo, mas continua válido que acho melhor consultar antes a equipe trabalhando no projeto antes de criar vários longos issues.

Quanto a fazer-cracia e etc, é por isso que não gosto desse conceitos vagos demais para serem interpretados da forma que for mais conveniente. Eu poderia argumentar que vou ignorar completamente suas sugestões (inclusive utilizar o issue tracker como fórum de discussão) simplesmente pelo fato de ser eu quem está desenvolvendo o projeto no quesito técnico. E não acho que essa postura seria muito produtiva.

Quanto ao label, outro ponto que não deverá ser discutido aqui, ok? É uma questão mais complexa e ainda tem que ser levado em consideração que os projetos da OKFN Brasil são realizados por grupos de desenvolvedores distintos com dinâmicas particulares a cada grupo.

Mas enfim, discussões teóricas a parte, vamos parar de dicutir isso por aqui e continuar na lista ok?

[ppKrauss]

A OKBr ainda tem muitas lacunas na sua governança e na proposta de governança dos projetos, acho que estão evoluindo, dentro da velocidade que o "feedback comunitário" e democracia permitem... Ok, concordo, ENCERRANDO POR HORA as discussões aqui no Github/issues, e voltando às discussões de projeto na lista (até termos uma definição mais formal da OKBr).