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

Quinta Abril 9 17:09:52 UTC 2015

+10 pra vocês Luiz! :)

Faço suas palavras minhas, hoje mesmo estava sugerindo que uma série
de discussões conceituais sobre o projeto Euvoto que foram criadas
nos Issues do Github fossem criadas nessa lista ao invés de lá.

Usemos os issues para propostas mais técnicas ou problemas reais
e atuais existentes no projeto do repositório. Além disso o código
de um projeto é fácil de ser migrado do Github para outro local,
as discussões e issues não.

Edgar

On 09/04/2015 14:00, Luiz Armesto wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> O wiki em geral fica reservado para documentação, faq, tutoriais,
> receitas e explicações consolidadas sobre o projeto, arquitetura e
> implementaçã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).
>
> 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.
>
> 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.
>
> 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".
>
> 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.
>
> 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".
>
> 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.
>
> 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.
>
> 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.
>
> []s
>
> 2015-04-09 12:12 GMT-03:00 Raniere Silva <raniere em riseup.net [10]>:
>
>>> 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 [1]) 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/ [2], http://talky.io/ [3],
>> http://meet.jit.si/ [4], ... até que desistimos.
>>
>> Raniere
>>
>> [1] https://en.wikipedia.org/wiki/Gitorious [5]
>> [2] https://en.wikipedia.org/wiki/GitHub [6]
>>
>> _______________________________________________
>> okfn-br mailing list
>> okfn-br em lists.okfn.org [7]
>> https://lists.okfn.org/mailman/listinfo/okfn-br [8]
>> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br [9]
>
> --
>
> Luiz Armesto
>
>
> Links:
> ------
> [1] http://github.com/datasets
> [2] http://apper.in/
> [3] http://talky.io/
> [4] http://meet.jit.si/
> [5] https://en.wikipedia.org/wiki/Gitorious
> [6] https://en.wikipedia.org/wiki/GitHub
> [7] mailto:okfn-br em lists.okfn.org
> [8] https://lists.okfn.org/mailman/listinfo/okfn-br
> [9] https://lists.okfn.org/mailman/options/okfn-br
> [10] mailto:raniere em riseup.net