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

Quinta Abril 9 17:05:37 UTC 2015

Sobre o usar o GitHub ou alguma alternativa totalmente livre, eu
pessoalmente não vejo muito problema no fato do código do GitHub não ser
100% livre e acho que o efeito rede faz com que ele seja vantajoso e ajude
a dimunir a barreira para termos colaboradores.

(uma colocação breve para compensar o email anterior :D )

[]'s

2015-04-09 14:00 GMT-03:00 Luiz Armesto <luiz.armesto em gmail.com>:

> 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>:
>
>> > 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
>

-- 
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150409/06aabb00/attachment-0005.html>