No contexto da comunicação OKBr, temos o BlogOKBr (ok.org.br), o DiscussOKBr (discuss.ok.org.br) e GitOKBr (git.ok.org.br). Todos eles permitem o uso de tags, e praticamente com a mesma ortografia — forçam minúsculas, não permitem espaços, etc.

Também, com o ticket #15, percebemos que um subconjunto das mesmas tags podem ser utilizadas na organização das pastas de backup, etc.

Na discuss.ok.org.org/3665/3 foi apresentada a solução de padronização das tags, que é retomada neste ticket já como proposta ação concreta do Suporte e diretiva para a Comunicação.

Problemas atuais

• Principalmente no DiscussOKBr, dada a diversidade de autores, eles nem todos usam as tags. A garantia de boas tags acaba então demandando trabalho de manutenção.

• A organização das tags, quando é feita, é feita olhando apenas para o espaço local, onde está sendo empregada, mas é preciso considerar a existência de outros dois espaços OKBr, para manter a compatibilidade.

Como consequência, a falta ou inconsistência de tags gera isolamento dos conteúdos (criamos ilhas ao invés de redes) e perda de oportunidades de automação, oportunidades de visualização amigável, de relacionamento, etc. Perde-se potencial de gestão de conteúdo e potencial de resolução semântica.

Solução proposta:

1. Padronizar as tags:
   1.1. Usar as mesmas palavras-chave (a serem empregadas como tags) em todos os espaços (Blog, Discuss, e Git).
   1.2. Não usar sinônimos, esforçar-se por reusar existentes e, quando preciso, criar tags padronizadas (ex. inspiradas nos termos SchemaOrg ou Wikidata).

2. Obrigar (recomendar) o uso de tags via Regimento Interno.
   PS: deveria ser tão importante quanto obrigar a ter o português corrigido.

3. Oferecer ferramentas amigáveis para os autores decidirem com rapidez qual tag usar: 3.1. Tesauro (dicionário de sinônimos e relacionamentos). 3.2. Listagens dinâmicas com exemplos mais populares.
   Algumas destas ferramentas já existem, a principal delas é a navegação das tags do Discuss, https://discuss.okfn.org/tags

Diretor OKBr e equipe do Projeto MediaLivre (libre-api), solicitam inclusão de botão no portal OKBr.

Conforme a pagina https://midialibre.org/app/sdk/gerar-botao basta incluir no local adequado o código HTML abaixo.

<!-- carrega o libre sdk -->
<div id="lbr-root"></div>
<script>(function(d, s, id) {
  var js, ljs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "https://midialibre.org/sdk/libre.js#v1.0;";
  ljs.parentNode.insertBefore(js, ljs);
}(document, 'script', 'libre-sdk'));
</script>

<!-- adiciona o botão do libre -->
<div class="lbr-button" data-id="67"></div>

Resta definir esse local adequado e modificar o nosso wordpress-theme... Se for possível via WP-Admin, melhor.

Hora de definir nomes de repositórios e organizar o que fica debaixo de cada nome. A sugestão ficou:

• Candidatos a backup:

  • Matérias do DOO.OK.ORG.BR
  • Relatórios e demais documentos oficiais da OKBr, seus programas ou projetos.
  • Relatórios, planilhas e demais documentos contábeis e de transparência
  • Produção da OKBR, tais como Guias, vídeos, etc.

• Todos os buckups ficam no repositório Git com assinatura SHA3-base58.

• Nome dos repositórios:

  • GIT.OK.ORG.BR/oficial-backups: para tudo, exceto "large files".
  • GIT.OK.ORG.BR/oficial-bigbackups: para "large files", tais como vídeos.

Tarefas subsequentes: resgatar o antigo DOO no backup e estabelecer formalmente os procedimentos no Regimento Interno... Por fim automatizar processos (assim como geração de relatórios e produtos editoriais bonitos) com ajuda do OFICIAL.NEWS.

Atualmente o site http://ok.org.br é redirecionado para domínio e infraestrutura da OKFN. Como tem apresentado diversos problemas, e como é baseado em Wordpress, como tema e backups totalmente disponíveis, não é difícil para a equipe de Suporte da OKBr instalar e manter o site.

O presente ticket, se aprovado, incorpora demandas do #5 e requisição de desenvolvimento do #8.

Sobre o ticket #17, depois que conquistarmos alguma padronização podemos pensar em automação...

Para Wordpress por exemplo já existe o plugin que sugere tags, https://wordpress.org/plugins/automatic-post-tagger/
Para Discuss está em discussão no Discourse.

O importante é que não seja totalmente automatizado, sempre haja decisão humana confirmando o que o algoritmo sugere. Um bom exemplo de "estado da arte" neste sentido é a automação de sugestão de tags no Stackoverflow

Precisa colocar o icone do Youtube no cabeçalho do site da OKBR. Junto com Twitter, Facebook e Discuss...
Apontar para: https://www.youtube.com/channel/UCi6vwmo9kWRRGYEmFR0kuIQ

Contexto: atualmente a infraestrutura Web da OKBR encontra-se hospedada na DigitalOcean (DO), e assim deve permanecer, estima-se que no mínimo por mais um ano.

Situação: para facilitar e profissionalizar a gestão dos domínios e máquinas virturais (droplets no jargão DO) criou-se uma equipe de administradores, coordenados neste momento pelo @cuducos. No admin DO o rótulo da equipe é "Open Knowledge Brasil". A máquina de referência recebeu o IP 159.65.236.56 159.203.118.136. Usuários deste time podem acessar o a gestão dos domínios em cloud.digitalocean.com/networking/domains/ok.org.br.

Tarefas:

1. recriar o droplet com certificados SSH dos responsáveis oficiais, únicos que terão acesso SSH.

2. certificar-se que a máquina (preferencialmente UBUNTU 18 LTS) esteja com firewall e sem permissão de SSH por login.

3. certificar-se de que o NGINX foi corretamente instalado e teve scripts de redirecioamento, pastas de hosting, etc. consistentes com o script antigo sites-available/ok.org.br.

4. copiar/colar (manualmente ou usando API DO) todas as entradas de CNAME, A, MX, etc. para o time, ou seja, o novo time é o proprietário do domínio ok.org.br e demais que forem anexados.

5. testar os redirecionamentos

PS: restaria avaliar o que fazer com o Wordpress e blog.ok.org.br, se vier a ser usado, abrir um novo ticket de suporte para retomar e descrever as tarefas.

A pedido da Diretoria da OKBr, conforme detalhes fixados em e-mail.

Problema: NGINX não subiu. Endereços e APIs não funcionavam. Servidor IP 107.170.30.160.

Detalhes do problema: status mostrando erro e service nginx restart não rodando, notificava "Job for nginx.service failed because the control process exited with error code"... Fazendo journalctl -xe:

-- Defined-By: systemd
...
Ago 21 19:53:29 oficial-news systemd[1]: Stopped A high performance web server and a reverse proxy server.
....
Ago 21 19:53:29 oficial-news nginx[2526]: nginx: [emerg] listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)
Ago 21 19:53:29 oficial-news nginx[2526]: nginx: [emerg] listen() to [::]:80, backlog 511 failed (98: Address already in use)
....
Ago 21 19:53:31 oficial-news nginx[2526]: nginx: [emerg] listen() to [::]:80, backlog 511 failed (98: Address already in use)
Ago 21 19:53:32 oficial-news nginx[2526]: nginx: [emerg] still could not bind()
Ago 21 19:53:32 oficial-news systemd[1]: nginx.service: Control process exited, code=exited status=1
Ago 21 19:53:32 oficial-news systemd[1]: Failed to start A high performance web server and a reverse proxy server.

Conferindo qual processo ainda estaria "zumbi" ou algo assim, sudo netstat -tulpn | grep --color :80:

tcp6       0      0 :::80                   :::*                    LISTEN      1828/apache2    

A OKBR vem administrando seus e-mails [email protected] através da plataforma G Suite, pois inscreveu-se num plano promocional gratuito, mas o mesmo vence em 2017. Não há como renovar a promoção, e o custo seria da ordem de US$5 por usuário.

Temos atualmente 44 usuários registrados, mas por volta de 20 com alguma atividade. Seriam portanto da ordem de US$100/mês a US$200/mês de despesa (R$300 a R$600), sendo que num servidor Linux próprio (que já temos) podemos gerenciar uma infinidade de contas de email, "sem" custo — com custo inicial de instalação e depois de suporte.

A melhor solução é continuar usando G Suite sem custo: isso é possível, através do plano for-nonprofits, pois a OKBr é reconhecida e inscrita juridicamente como entidade sem fins lucrativos.

Solicitação de suporte técnico/administrativo da diretoria da OKBr: avaliar como migrar do atual plano promocional para um definitivo tipo for-nonprofits. Cadastrar-se se não houverem maiores impactos.
PS: além das caixas de e-mail pode-se fazer uso de outros serviços, tais como CRM.

Ver https://discuss.ok.org.br/4967/10, "Domínios onde a OKBr é co-proprietária".

• preenchimento dos campos nas planilhas: aguardar estabilização da discussão;
• transparência e controle: citar contrato de co-propriedade quando existir.

Um bug só é bug se existe algum referencial, algum consenso muito claro sobre o que é (ou o que é falha e o que não é)... Ter texto duplicado entre Blog-OKBr e Canal-Medium-OKBr é falha?

Exemplo: esse bom texto e depoimento de Anca Matioc,
http://medium.ok.org.br/d/2e4b910a30ab
está duplicado no blog,
https://br.okfn.org/2015/12/07/governo-aberto-e-teatro-politico-para-os-corruptos

Como não tem nada escrito em lugar algum — falta um Regimento Interno para podermos aqui no Suporte traduzi-lo em regras de manutenção — então o Suporte não pode "dar suporte" quanto a este suposto problema... Ainda não é formalmente um problema.

Ainda em estudo.

O Github oferece recursos para a autorização de robôs (software agents similares aos Wikipedia bots): ver https://help.github.com/articles/connecting-with-third-party-applications/

Um primeiro está avaliado, e a partir dele poderemos formular os compromissos e obrigações da equipe de suporte ao acolher e controlar o uso de bots. Sugestão de @danfowler em neste disucssão, com a comunidade Frictionless Data discutindo neste tópico.

Copiando trecho de e-mail da Elza que explica a demanda,

(...) Há um tempo estou tentando descobrir a publicação automática que temos atualmente no Twitter. Assim que publicamos uma nota no blog, ele faz um tweet. Gostaria de desativar isso no blog, mas não consegui. (...)

MySQL e MariaDB são funcionalmente equivalentes, compartilham 100% do que se designa como "interface MySQL padrão". O MySQL, todavia, foi adquirido pela Oracle em 2010, o que comprometeu fortemente o imparcialidade das decisões do projeto. A comunidade open source todavia contribui (otimiza ano a ano) e tem direito de participação integral (democrático e meritocrático) no projeto MariaDB, por ser mantido pela MariaDB Foundation.

Já considerado um projeto estável e maduro, a própria distribuição Debian optou por substituir MySQL por MariaDB a partir de 2015 (versão 10 do MariaDB).

A política dos principais usuários open-source de MySQL tem sido da substituição.

MariaDB is the relational database management system used by the Wikimedia Foundation, Mediawiki/Manual:MySQL

Na OKBr a substituição faz sentido não apenas por questões técnicas e de estabilidade, mas também por questões morais e de consistência com seus princípios institucionais.

Os dados abertos gerados ou mantidos (backups) pela OKBr em seus projetos (ou programas contínuos) são oferecidos ao público de duas formas:

• Em datasets organizados como datasets-br.

• Através da API de bancos de dados dos sistemas mantidos pela OKBr, como no Gastos Abertos, Diário Livre, Cuidando, e outros.

Alguns datasets ainda podem ser melhor organizados e dispostos no datasets-br. A maior parte dos dados, todavia, vem das APIs. É necessário:

1. Catalogar todas as APIs e datasets da OKBr!

2. Revisar o status de documentação das APIs e datasets.

3. Avaliar se alguma API pode alimentar diretamente o datasets-br, ou ser transformada em dataset.

4. Avaliar se a infraestrutura de backend pode ser unificada ou padronizada.

O uso de API-gateway está sendo recomendado, assim como a sua documentação em OpenAPI.
Exemplo de iniciativa de documentação: http://api.ok.org.br

Relatório de revisão da situação atual dos servidores, com base em tabelas similares à okfn-brasil/discussOKBr-assets/data/servidores.csv, estabelecendo eventualmente o encerramento de uma das máquinas. Serviços de balanceamento de carga, atualização da versão do sistema e ferramentas instaladas, etc.

A interface do Wordpress produz um diálogo local no rodapé da página. É importante que esteja visível lá, por ser uma extensão do conteúdo e um termômetro da receptividade, polêmica ou relevância em torno do conteúdo do artigo... Mas na OKBr temos um local mais adequado para discussões, que é o http://discuss,ok.org.br (DiscussOKBr),

A solução é fazer mais ou menos o que o Ariel fez neste artigo de entrevista com o Santiago: a existência do post de comentário fica registrada por seu link, talvez até pelo seu texto, mas a discussão em si passa para o DiscussOKBr. Ou seja, a solução é automatizar essa estratégia.

RESUMO: este ticket é uma sugestão de diretiva para o suporte e o desenvolvimento, e tem como foco a redução de barreiras no tratamento anti-spam dos cadastros e formulários de feedback, podendo ser resumida em duas regras,

1. não usar sistemas de proof-of-work que sejam barreira de acessibilidade,
   e evitar sempre que possível o seu uso, mesmo quando não seja barreira.

2. Contentar-se com medidas que barrem 50% a 90% das tentativas frequentes de spam ou vandalismo. Os 10% restantes, se representarem qualquer perda de atratividade ao cadastro de novos usuários, deverá ser resolvido por humanos voluntários, moderadores da própria OKBr ou projeto da OKBr.

Justificativas

O artigo indicado pela Elza, https://tableless.com.br/eu-nao-sou-uma-maquina/
explica muito bem os inconvenientes do CAPTCHA ou mesmo outros meios de proof-of-work. Fica a sugestão de regra geral, de não usar. O suporte dá todo apoio para usuários obterem login e/ou reusarem login do OpenID, Github, Face, Google, etc.

Na maior parte das inteirações com sistemas e serviços OKBr ou de transparência, a identificação é considerada boa-prática, e não se justifica anonimato.

No Blog

No ticket#16 sugere-se alternativa bem diferente: forçar toda a interatividade no DiscussOKBr.

No DiscussOKBr e similares

Além de forçar o login, não se justificam CAPTCHA ou outras medidas-extra, tendo em vista que o número de moderadores "dá e sobra" para a limpeza das tentativas de cadastramento de spammers.
Estamos dando preferência ao nosso lado humano e voluntário, como na Wikipedia ou Stackoverflow, que contam com o ser exército de faxineiros anti-spam e anti-vandalismo. Acaba sendo também uma medida do quanto a comunidade ainda está viva.

Nos projetos OKBr

Vide indetificação no Cuidando.org.br e GastosAbertos.org.

Disponibilidade do suporte para atender prontamente aos pedidos de atenção no DiscussOKBr, para novos usuários com alguma denúncia sobre seus posts ou novos tópicos.

As ocorrências de vandalismo são aleatórias, e como existem outros administradores, pode-se estimar com o tempo um valor de demanda limitado (por exemplo estimativa de 2 chamados por mês). Apesar de simples (2 a 5 minutos para análise e efetivação de ações) envolve grande responsabilidade:

• a comunidade OKBr deve confiar nos administradores destacados para dar este tipo de suporte.

• há grande grau de atenção e responsabilidade, pois um equivoco do administrador terá grande impacto sobre o usuário afetado e sobre a própria comunidade.

Métrica: quando o investimento de tempo do administrador for registrado, sugere-se estimar 5 minutos por evento de suporte, contabilizando-se formalmente apenas o número de eventos de suporte realizados.

Limites: em caso de cobrança pelas horas de suporte, importante a cláusula de limite de tickets relativos ao "vandalismo no espaço discuss.okfn.org", ficando tickets adicionais como trabalho voluntário. Sugeres-se neste momento o máximo de 5 tickets/mês.

Exemplos concretos de trabalho de gestão.

• Após confirmação solicitada ao administrador mais antigo (@danfowler) o administrador @ppkrauss deletou o usuário de e-mail [email protected] que postou tópico de vandalismo. A mensagem chegou por email ao @ppkrauss , "A post in '[email protected]' requires staff attention".

• O tópico com problema mais evidente, já pelo seu título, "Tfrtwergdf Tsrtwtgxfsdf", do novo usuário @serwetsdfgr foi deletado, assim como o próprio usuário.

Solicitação do Diretor da OKBr para dar andamento (cotação) aos serviços implícitos ou propostos no tópico Direitos de propriedade da OKBR, eventualmente alinhando-se com a formulação das regras de usufruto em discussão neste tópico.

A empreitada envolve também organizar os dados publicamente em okfn-brasil/discussOKBr-assets/data.

O foco dos serviços Github, onde hospedamos gratuitamente todos nossos backups, não é a oferta de hosting. Oferecer links de PDF no Github, simplesmente para não sobrecarregar nosso Web-server, pode eventualmente se mostrar um mau negócio devido à frequência de interrupções ou lentidão.

Hoje tivemos durante a manhã inteira a falha "Error 503 first byte timeout" nos downloads vinculados ao BAIXAR.OK.ORG.BR (exemplo). Esse foi o comunicado da Github,

Segundo relato da Elza o serviço já havia se normalizado por volta das 12h, de modo que foram por volta de 3 horas de interrupção nos serviços.

Sugestão

Registrar próximas ocorrências por aqui (por favor comunique e/ou ajudem a registrar!).

Se de fato ocorrem com frequência (ex. todo mês ou toda semana), uma estratégia seria transformar o BAIXAR.OK.ORG.BR, que já é um proxy reverso, em um software de cache, mantendo os arquivos mais solicitados no nosso servidor-web.

Atualmente a URL HTTP://OK.ORG.BR cai numa página vazia, por oferta do RegistroBr com seu servidor DNS sec.dns.br. Será alterado para ns1.digitalocean.com que é onde temos nosso hosting.

JUSTIFICATIVA: preparar a infraestrutura para cumprir com os redirecionamentos previstos na nova regra discutida.

RISCO: não sabemos o que pode ocorrer com os registros de MX, que garantem a circulação dos e-mails, e estão sendo mantidos atualmente pela ferramenta G-Suite. Se der algum problema é só registrar o MX no gerenciador de DNS da Digitalocean, mas entre detectar o problema, incluir o MX e aguardar a sua propagação, o serviço de e-mail OKBr pode ficar indisponível, no pior caso, por 2 dias.

Projetos git da OKBr em https://github.com/datasets-br e https://github.com/okfn-brasil sendo obtidos a partir de domínio OK.ORG.BR, evitando que a OKBr fique refém do Github. Teria liberdade de passar por exemplo para o GitLab sem perder os links e comandos já registrados em comunicações internas, sites externos, documentação, CD-ROMs, etc.

Exemplos:

• git clone http://datasets.ok.org.br/state-codes.git resultaria no mesmo que https://github.com/datasets-br/state-codes.git.

• git clone http://git.ok.org.br/hackathons.git resultaria no mesmo que https://github.com/okfn-brasil/hackathons.git.

Isso é importante para a divulgação dos endereços

NOTA

Salientar sempre que o clone não é relativo a HTTPS mas HTTP, para garantir que o certificado de segurança junto com o redirecionamento, não antes dele. Mesmo que o HTTPS://git.ok.org.br seja válido, não pode ser utilizado em outro domínio: isso acarreta "fatal: unable to access (...) SSL: certificate subject name (oficial.news) does not match target host name".