[okfn-br] grande ajuda nos projetos OKBr: vote na issue!

Quarta Abril 15 13:25:37 UTC 2015

Oi Luiz, tive problemas técnicos com a lista, estou arrumando... Mas estou
em divida com uma resposta para voce (!),
fique a vontade para jogar na lista se achar necessário.  Este seu e-mail
veio de
         Digest okfn-br, volume 45, assunto 30
(justamente por esse Digest  tb fiquei impedido de participar da Reuniao de
Conselho, que só agora cedo me enviou o hangout)

2015-04-09 14:00 GMT-03:00 <okfn-br-request em lists.okfn.org>:

>
>
> ---------- Mensagem encaminhada ----------
> From: Luiz Armesto <luiz.armesto em gmail.com>
> To: "Grupo de interesse em conhecimento livre no Brasil, especialmente
> dados abertos // Open Knowledge discussion list for Brazil" <
> okfn-br em lists.okfn.org>
> Cc:
> Date: Thu, 9 Apr 2015 14:00:11 -0300
> Subject: Re: [okfn-br] grande ajuda nos projetos OKBr: vote na issue!
> Antes de mais nada, desculpem pelo tamanho do email. rs
>
>
> Sobre centralizar tudo no github, não acho uma ideia tão boa. Em geral os
> projetos open source possuem alguns canais de comunicação: wiki, lista(s)
> de discussão, issue tracker e canal IRC.
>
>
Não se trata de "centralizar tudo": precisamos evitar distorções sobre a
proposta (senão sai todo mundo correndo), pois não é essa.
Se trata de especializar, como tudo: se não houver fórum especifico para
debater o projeto e questões altamente chatinhas e especificas do projeto,
vai apenas poluir a lista geral e fazer as pessoas debandarem da lista,
pois toma tempo filtrar emails relevantes... E poderia ser uma outra lista,
mas não precisa: o git envia email avisando que tem posts novos no /issues.

> Pode parecer que tantos canais assim dificultem a comunicação, por
> espalhar muito as informações, mas na realidade eles dimunuem os ruídos ao
> centralizarem contextos distintos em canais diferentes.
>

Exato (!)

>
> O canal IRC é destinado para tirar dúvidas rápidas e imediatas sobre
> assuntos que, em geral, não precisam ser arquivados para consultas futuras.
> É usado tanto pelos desenvolvedores quanto pela comunidade. Inclui
> perguntas sobre dificuldade na instalação ou uso de algum programa,
> dificuldade de acesso a algum serviço, comunicação síncrona entre os
> desenvolvedores enquanto estão trabalhando para esclarecer alguns detalhes
> ou dúvidas pontuais e até conversas aleatórias entre as pessoas envolvidas
> ou interessadas no projeto.
>

Hum... Mas existe algum IRC da OKBr?  Alguém está usando?

>
> A lista de discussão pode ser única ou separada em "geral" e
> "desenvolvimento". Na geral normalmente se discute os objetivos do projeto,
> caminhos a se seguir, popõe-se alterações ou melhorias em um nível mais
> abstrato, tira-se dúvidas não urgentes (ou mesmo urgentes quando não for
> possível no canal IRC), dar e pedir opiniões, conversar sobre assuntos
> diversos relacionados ao projeto, fazer anúncios. Na de desenvolvimento se
> discute coisas parecidas mas com foco mais técnico, sobre tecnologias
> usadas, arquitetura, detalhes de implementação, problemas ou dúvidas sobre
> o código para os quais ainda não se tem decidido como solucionar, etc.
>

Extato, precisaria no mínimo dessa separação de "geral" e "o resto".. Mas
justamente "o resto" não é apenas desenvolvimento, e o mundo evoluiu depois
da invenção das listas, o github/issues tem as duas vantagens:

* é específico e intimamente amarrado ao projeto

* é um recurso sofisticado, muito superior a uma lista, que abrange também
papel de bugtracking e geração de tickets, ou seja, contempla requisitos de
"governança do projeto" que tanto falam (e pouco fazem) no Conselho da OKBr.

>
> O wiki em geral fica reservado para documentação, faq, tutoriais, receitas
> e explicações consolidadas sobre o projeto, arquitetura e implementação.
>
>
Ok, acho que é por ai, mas existe um "dilema" entre "Wiki do git/projeto"
(simples de usar é só incentivar) e "Wiki da OKBr que na prática ninguém
usa"...
... daria mais uma longa discussão :-)

> As issues servem em geral para criar tarefas para implementar aspectos do
> projeto que já foram discutidos (nas listas de discussão preferencialmente
> ou em reuniões presenciais) e já são consenso, reportar erros ou mesmo para
> fazer perguntas e dar algumas sugestões para os desenvolvedores (em geral
> usado por pessoas que estão tento um primeiro contato, para a comunidade é
> preferível usar as listas de discussão).
>
>
Sim, há que se ter um "filtro", uma "curadoria" sobre o que se posta nas
issues, e essa é a tarefa do coordenador do projeto (e sua equipe)

>
> Mas como que essa coisa espalhada diminui o ruído?
>
> Nos projetos sempre tem no mínimos pessoas interessadas em dois pontos,
> podendo ou não se sobrepor: aspecto técnico e objetivos finais do projeto.
>
>
isso, legal, podemos talvez começar um "tutorial dos meios de comunicação
nos projetos OKBr" com o seu texto (!).

> Quem coloca a mão na massa e toca o projeto se envolve. em maior ou menor
> grau, em todos os aspectos, mas tem quem se interesse em apenas um e não
> queira receber notificações sobre os outros. No Gastos Abertos, por
> exemplo, podemos ter muita gente interessada em transparência da máquina
> pública, visualização e análise dos dados, mas que não quer saber se
> estamos usando python, flask, nodejs, RoR, se a arquitetura é monolítica ou
> são vários serviçoes distribuídos et etc. Isso não é algo que afetará
> diretamente os interesses nem a participação dela no projeto, podendo tirar
> o foco enquanto ela tenta entender o que isso tudo significa e se dar conta
> que pra ela não importa.
>

Devo lembrar que (no Github) cada issue recebe um label, e o label
caracteriza o tipo de discussão e o tipo de comunidade.
label "bug" = apenas equipe de desenvolvimento tem interesse em estudar, e
a comunidade usuária de saber que já foi registrado.
label "new issue" = a equipe de desenvolvimento tem interesse em estudar e
precisa dar um parecer, mas a comunide participa, não pode ser muito
técnico.
label "discussion" = todos participam, e quando a equipe desenvolvedora
está sem tempo, pode ignorar.
label ... = seria legal a OKBr padronizar alguns rótulos para sinalizar
mais claramente quem consultar as listagens de /issues.

>
> Mesmo para quem se envolve no projeto como um todo determinados assuntos
> podem se tornar ruído dependendo do contexto. Eu, como desenvolvedor,
> separo um tempo para me dedicar aos assuntos gerais dos projetos que
> participo e outro para me dedicar à implementação. Vou chamar de "modo
> geral" e "modo developer".
>
>
sim, reforça o que coloquei acima sobre *labels*.

> Quando estou no "modo geral" eu presto atenção em notificações da lista de
> discussão geral, modificações na wiki e canal IRC e um pouco na lista de
> desenvolvimento. Quando no "modo developer" me concentro nas Issues, na
> lista de discussões de desenvolvimento e no canal do IRC.
>
>
ok

> Então quando estou escrevendo código, pensando em implementação, testando
> algo e recebo uma notificação que uma issue foi criada ou alguém comentou
> algo, e não tem alguem responsável por fazer a triagem (apenas projetos
> muito grande costumam ter), eu paro o que estou fazendo e vou ver o que é,
> esperando que seja algo diretamente relacionado ao desenvolvimento.
> Normalmente é por alí que vou ficar sabendo se alguém achou algum erro
> crítico que precisa de atenção imediata, quais tarefas eu vou me dedicar no
> dia, o que cada um vai fazer ou está fazendo. Se começar a aparecer muitas
> notificações sobre discussões gerais a consequencia natural é a principio
> perder o foco durante o desenvolvimento e em seguida começar a ignorar as
> notificações, deixando passar algoque seria importante para o "modo
> developer".
>

Não concordo com tudo: num projeto grande e "assediado" como o Gastos
Abertos é fundamental a figura do coordenador ou daquele que for delegado a
avaliar e rotulas as coisas com devidos *labels*. Antes de receber um label
a issue pode ser ignorada por toda a equipe, depois de receber um label,
cada membro da equipe pode ou não "estar sendo chamado" pela issue.

>
> Quando vou responder algo na lista de discussão geral eu me contenho para
> não usar termos técnico e não entrar em detalhes de como poderia ser
> implementado, pois sei que não é o local para isso e os demais podem não
> estar interessados ou não entenderem. Com tudo junto isso complica, pois
> não saberei tão facilmente qual o nível de abstração usar.
>

isso, na prática concordamos em algo que ninguém gosta de assumir na OKBr:
regras são necessárias. Sem regras a comunidade OKBr não evolui e não da
conta da demanda já existe pela profissionalização... (ok outra longa
discussão, não vamos nos dispersar :-)

>
> No caso o IRC, que é algo que fica aberto o tempo todo que me dedico ao
> projeto, quando estou no "modo developer" eu acabo ignorando assuntos em
> geral e só me ligo quando alguém me cita explicitamente na conversa, quando
> estou no "modo geral", de tempos em tempos dou um espiada pra ver se alguém
> falou algo e se der eu ajudo.
>
>
Por hora vou ignorar comentários sobre o IRC, já que não o vi pela OKBr,
talvez seja algo do Gastos Abertos.

> Isso sem contar a possibilidade de um projeto poder ter N repositórios, o
> que bagunçaria ainda mais. Alguns acabariam usando a estrutura de um
> repositório, outros de outro. Teria coisas relacionadas ao que é
> implementado no repositório A sendo discutida no repositório B. Na hora de
> procurar algo que foi dito teria-se que visitar todos. Bem caótico.
>

Novamente é caso simplíssimo (!) de *estabelecer regras/convenções*. Regra
de nomenclatura de repositórios: apenas um deles (e pode ser um mero README
e só) recebe o nome do projeto, o resto receberia alem do nome um sufixo.
As discussões e issues gerais seriam todas levadas para esse "repositório
mestre".

.. Regras/conveções não precisam existir exceto quando são a solução de um
"dilema social". Marcar hora e local de reunião do Conselho por exemplo é
uma convenção pontual, mas é uma convenção, caso contrário ninguém se
encontraria... São os chamados "problemas de coordenação
<https://en.wikipedia.org/wiki/Coordination_game>"...

Peter

>
>
> []'s
>
> 2015-04-09 12:12 GMT-03:00 Raniere Silva <raniere em riseup.net>:
>
>> > PS: quanto ao mérito do Github, de ser ou não uma plataforma
>> > "ideologicamente compatível" com o OKBr, devo lembrar que até o W3C (e a
>> > OK-I no github.com/datasets) já migrou para o Github... No meu ver é
>> como
>> > *hangouts*, precisamos dele, por hora não há "solução livre" compatível
>> com
>> > o grau de confiabilidade/estabilidade e sofisticação que esperamos.
>>
>> São problemas totalmente diferentes.
>>
>> Desde 2008 [1] temos uma solução 100% livre ao GitHub,
>> sendo que ela surgiu primeiro que o GitHub [2].
>> Então não estamos usando algo 100% livre porque queremos.
>> Se pessoas/organizações continuam aderindo ao GitHub
>> é apenas pelo efeito de rede.
>>
>> O Google Hangouts é um problema totalmente diferente.
>> As soluções livres possuem muitas limitações,
>> principalmente em relação ao uso de vídeo.
>> Eu falo com conhecimento de causa porque o grupo de ciência aberta
>> tentou utilizar http://apper.in/, http://talky.io/,
>> http://meet.jit.si/, ... até que desistimos.
>>
>> Raniere
>>
>> [1] https://en.wikipedia.org/wiki/Gitorious
>> [2] https://en.wikipedia.org/wiki/GitHub
>>
>> _______________________________________________
>> okfn-br mailing list
>> okfn-br em lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/okfn-br
>> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>>
>>
>
>
> --
> Luiz Armesto
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150415/0b013b51/attachment-0005.html>