Concordo com o Luiz. Como desenvolvedor me sinto mais a vontade em contribuir em projetos que estejam no Github do que em outras plataformas pois 98% dos códigos que trabalho estão nesta plataforma.
2015-04-09 14:09 GMT-03:00 Edgar Zanella Alvarenga <[email protected]>: > +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 <[email protected] [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 >>> [email protected] [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:[email protected] >> [8] https://lists.okfn.org/mailman/listinfo/okfn-br >> [9] https://lists.okfn.org/mailman/options/okfn-br >> [10] mailto:[email protected] >> > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > -- Danilo Amaral de Oliveira Engenheiro de Computação celular (11) 95282-3504
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
